From gambas at ...538...  Thu Jan  3 20:03:38 2008
From: gambas at ...538... (MV)
Date: Thu, 3 Jan 2008 20:03:38 +0100
Subject: [Gambas-devel] Build failed for Gambas 2.0.0
Message-ID: <200801032003.39326.gambas@...538...>

Hello,

I've just built the latest gambas from source, and I hit bugs. My system is 
loosely based on an old fedora core 2 that I patched quite heavily, but 
otherwise running fine (yes, in other words, it's a mess). If nobody else has 
troubles, well, it may be time I upgrade to a state of the art ubuntu, but 
for the record, I think I should share my journey in the building of gambas2:

- configure left out various bits and pieces I didn't care about (gtk, pdf, 
firebird, mysql and such). In the past ('til gambas 1.9.47, the last I 
compiled) it has never been a problem. I noticed a new gb.desktop component 
(I didn't knew existed before) that was left out, but I thought it wouldn't 
matter. Otherwise, no errors.

- Make was doing its job until it reached /gb.qt.ext/ where it failed with 
something like "LD can't figure out where -lX11 is pointing to" (just 
kidding, but that was the meaning). So I picked a look at libtool in that 
particular directory, to no avail, and as time was running, I finally did it 
the old way : I cut and pasted the faulty lines in another terminal, replaced 
"-lX11" with a qualified path "-L/usr/X11R6/lib", and when that was done, 
restarted make. I had to perform the same trick to build successfuly /gb.qt/, 
too. 

- So finally, gambas managed to build seamingly successfully, I tried to run 
it and *bam* error : the desktop component is required to run the IDE. As it 
turns out, the configure test in /gb.desktop/ failed to find a function in 
libXext [XTestQueryExtension(), defined in XTest.h on my system]. As I had 
the header, and was frustrated, I supplied a sounding 'yes' by hand in the 
configure script, and after that the component built without a hitch.

- Not anymore, really ? Well, tough luck. Libtool couldn't again find where 
-lX11 was pointing, so I had to revert to the cut-and-paste routine I already 
mentionned.

So I finally managed to launch gambas and everything that I otherwise compiled 
seems to work ; well that's if don't take into account a little hotfix(*) I 
had to apply to build CWebbrowser.cpp, but I assume my kde libs are totally 
outdated, so this I don't really mind.

All in all : congrats for the good job, gambas is shinnier than ever, but the 
more I build it, the more I find it picky with its requirements. I wish 
autoconf/automake were more friendly (some tests are performed again for each 
component, finding the relevant info is kind of looking for a needle in a 
haystack), and I'd really love to know exactly which libs are required to 
make a successful build, especially what versions are considered minimum.

Otherwise, cheers !

(*) hotfix in the for of commenting out a couple of function calls getting in 
my way, declared 'private' in the header as far as gcc tells me. Chances are 
that I won't be able to select text in the component ;-)
-- 
Manuel Viet




From jredrejo at ...176...  Thu Jan  3 20:03:48 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Thu, 3 Jan 2008 20:03:48 +0100
Subject: [Gambas-devel] Build failed for Gambas 2.0.0
In-Reply-To: <200801032003.39326.gambas@...538...>
References: <200801032003.39326.gambas@...538...>
Message-ID: <8eb28a500801031103u3d091686q48ec48cf246cbc16@...178...>

2008/1/3, MV <gambas at ...538...>:
>
> Hello,
>
> I've just built the latest gambas from source, and I hit bugs. My system
> is
> loosely based on an old fedora core 2 that I patched quite heavily, but
> otherwise running fine (yes, in other words, it's a mess). If nobody else
> has
> troubles, well, it may be time I upgrade to a state of the art ubuntu, but
> for the record, I think I should share my journey in the building of
> gambas2:
>
> - configure left out various bits and pieces I didn't care about (gtk,
> pdf,
> firebird, mysql and such). In the past ('til gambas 1.9.47, the last I
> compiled) it has never been a problem. I noticed a new gb.desktopcomponent
> (I didn't knew existed before) that was left out, but I thought it
> wouldn't
> matter. Otherwise, no errors.
>
> - Make was doing its job until it reached /gb.qt.ext/ where it failed with
> something like "LD can't figure out where -lX11 is pointing to" (just
> kidding, but that was the meaning). So I picked a look at libtool in that
> particular directory, to no avail, and as time was running, I finally did
> it
> the old way : I cut and pasted the faulty lines in another terminal,
> replaced
> "-lX11" with a qualified path "-L/usr/X11R6/lib", and when that was done,
> restarted make. I had to perform the same trick to build successfuly
> /gb.qt/,
> too.
>
> - So finally, gambas managed to build seamingly successfully, I tried to
> run
> it and *bam* error : the desktop component is required to run the IDE. As
> it
> turns out, the configure test in /gb.desktop/ failed to find a function in
> libXext [XTestQueryExtension(), defined in XTest.h on my system]. As I had
> the header, and was frustrated, I supplied a sounding 'yes' by hand in the
> configure script, and after that the component built without a hitch.
>
> - Not anymore, really ? Well, tough luck. Libtool couldn't again find
> where
> -lX11 was pointing, so I had to revert to the cut-and-paste routine I
> already
> mentionned.
>
> So I finally managed to launch gambas and everything that I otherwise
> compiled
> seems to work ; well that's if don't take into account a little hotfix(*)
> I
> had to apply to build CWebbrowser.cpp, but I assume my kde libs are
> totally
> outdated, so this I don't really mind.
>
> All in all : congrats for the good job, gambas is shinnier than ever, but
> the
> more I build it, the more I find it picky with its requirements. I wish
> autoconf/automake were more friendly (some tests are performed again for
> each
> component, finding the relevant info is kind of looking for a needle in a
> haystack), and I'd really love to know exactly which libs are required to
> make a successful build, especially what versions are considered minimum.
>
>
You're mostly right, component developers use to keep on the edge and
configure files are built according to the libraries versions they're using.
So, you need a very updated system to be able to compile gambas,
nevertheless the distribution you're using, if you want to go on with Fedora
you can, but you must update to its latest version.
On the other hand, I've uploaded version 2.0 some hours ago, and maybe
checking its build dependencies could help you. You'll have to wait some
hours for the http://packages.debian.org/source/sid/gambas2 page to be
updated with the latest dependencies, but, as an example: your libXext error
needs more than the headers, in Debian you need to install libxtst-dev, and
these are the files it contains:
http://packages.debian.org/lenny/i386/libxtst-dev/filelist

Regards.
Jos? L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080103/271ec42c/attachment.html>

From gambas at ...538...  Fri Jan  4 03:46:51 2008
From: gambas at ...538... (MV)
Date: Fri, 4 Jan 2008 03:46:51 +0100
Subject: [Gambas-devel] Build failed for Gambas 2.0.0
In-Reply-To: <8eb28a500801031103u3d091686q48ec48cf246cbc16@...178...>
References: <200801032003.39326.gambas@...538...>
	<8eb28a500801031103u3d091686q48ec48cf246cbc16@...178...>
Message-ID: <200801040346.52028.gambas@...538...>

Thank you very much for your prompt reply. I've been toying for a couple of 
hours with gambas, and it was worth the effort. I just thought it might be 
mildly funny to read it, as well as providing some hints for those unlucky 
enough to be trapped like I was.

> your libXext
> error needs more than the headers, in Debian you need to install
> libxtst-dev, and these are the files it contains:
> http://packages.debian.org/lenny/i386/libxtst-dev/filelist

I wasn't really clear : I had both the headers and the library itself. I 
certainly installed the dev part of the package. But for some reasons, this 
is not enough anymore. From the file you pointed me to, I was only missing 
the pkgconfig declaration. That really irritates me. The more the auto 
packagers try to be smart, the more one runs up in walls like this one, and 
those are completely arbitrary as otherwise the really needed bits are 
correctly installed, in the lib_path, and ldconfig knows them. Soon, we'll 
have config files pointing to helper files directing to list files containing 
references to variables holding relative paths to something we need to find 
the library. Not gambas' team fault, of course :-)

Best wishes for this new year,

-- 
Manuel Viet




From rospolosco at ...29...  Fri Jan  4 10:19:49 2008
From: rospolosco at ...29... (Stefano Palmeri)
Date: Fri, 4 Jan 2008 10:19:49 +0100
Subject: [Gambas-devel] Build failed for Gambas 2.0.0
In-Reply-To: <200801040346.52028.gambas@...538...>
References: <200801032003.39326.gambas@...538...>
	<8eb28a500801031103u3d091686q48ec48cf246cbc16@...178...>
	<200801040346.52028.gambas@...538...>
Message-ID: <200801041019.49632.rospolosco@...29...>

Alle 03:46, venerd? 4 gennaio 2008, MV ha scritto:
> Thank you very much for your prompt reply. I've been toying for a couple of
> hours with gambas, and it was worth the effort. I just thought it might be
> mildly funny to read it, as well as providing some hints for those unlucky
> enough to be trapped like I was.
>
> > your libXext
> > error needs more than the headers, in Debian you need to install
> > libxtst-dev, and these are the files it contains:
> > http://packages.debian.org/lenny/i386/libxtst-dev/filelist
>
> I wasn't really clear : I had both the headers and the library itself. I
> certainly installed the dev part of the package. But for some reasons, this
> is not enough anymore. From the file you pointed me to, I was only missing
> the pkgconfig declaration. That really irritates me. The more the auto
> packagers try to be smart, the more one runs up in walls like this one, and
> those are completely arbitrary as otherwise the really needed bits are
> correctly installed, in the lib_path, and ldconfig knows them. Soon, we'll
> have config files pointing to helper files directing to list files
> containing references to variables holding relative paths to something we
> need to find the library. Not gambas' team fault, of course :-)
>
> Best wishes for this new year,

I had the same problem with LD not finding libxtst (even if it was already 
installed); but there's an easy solution. 

When you want to compile Gambas type on console:

export LDFLAGS="-L/usr/X11R6/lib" 
./configure


Regards, 

Stefano



From gambas at ...1...  Sat Jan  5 12:26:08 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sat, 5 Jan 2008 12:26:08 +0100
Subject: [Gambas-devel] Build failed for Gambas 2.0.0
In-Reply-To: <200801032003.39326.gambas@...538...>
References: <200801032003.39326.gambas@...538...>
Message-ID: <200801051226.09033.gambas@...1...>

On jeudi 3 janvier 2008, MV wrote:
> Hello,
>
> I've just built the latest gambas from source, and I hit bugs. My system is
> loosely based on an old fedora core 2 that I patched quite heavily, but
> otherwise running fine (yes, in other words, it's a mess). If nobody else
> has troubles, well, it may be time I upgrade to a state of the art ubuntu,
> but for the record, I think I should share my journey in the building of
> gambas2:
>
> - configure left out various bits and pieces I didn't care about (gtk, pdf,
> firebird, mysql and such). In the past ('til gambas 1.9.47, the last I
> compiled) it has never been a problem. I noticed a new gb.desktop component
> (I didn't knew existed before) that was left out, but I thought it wouldn't
> matter. Otherwise, no errors.
>
> - Make was doing its job until it reached /gb.qt.ext/ where it failed with
> something like "LD can't figure out where -lX11 is pointing to" (just
> kidding, but that was the meaning). So I picked a look at libtool in that
> particular directory, to no avail, and as time was running, I finally did
> it the old way : I cut and pasted the faulty lines in another terminal,
> replaced "-lX11" with a qualified path "-L/usr/X11R6/lib", and when that
> was done, restarted make. I had to perform the same trick to build
> successfuly /gb.qt/, too.
>

Hi,

I have modified some little things in the X11 detection code. Could you 
checkout the 3.0 trunk and test it on your system? You don't have to compile 
everything, just one X11 component like gb.desktop.

Thanks in advance if you could do that.

Regards,

-- 
Benoit Minisini



From gambas at ...1...  Sun Jan  6 20:02:22 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 6 Jan 2008 20:02:22 +0100
Subject: [Gambas-devel] New branch for 64 bits development
Message-ID: <200801062002.23288.gambas@...1...>

I have created a new svn branch dedicated to the 64 bits port. I hope that, 
this way, I will be able to eventually backport it to the 2.0 version if 
needed.

Regards,

-- 
Benoit Minisini



From jredrejo at ...176...  Sun Jan  6 20:45:47 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Sun, 6 Jan 2008 20:45:47 +0100
Subject: [Gambas-devel] New branch for 64 bits development
In-Reply-To: <200801062002.23288.gambas@...1...>
References: <200801062002.23288.gambas@...1...>
Message-ID: <8eb28a500801061145h5b3d218ao17a3670eaf508b26@...178...>

You're great Beno?t, but an idea is around my mind for the last days: you
deserve a rest after the 2.0 release, haven't you felt the need to unplug
every computer for some days and doing just nothing?
Don't misunderstand me: I'm happy seeing your advances everyday, but I'm
beginning to think you're not human ;-)

Cheers.
Jos? L.

2008/1/6, Benoit Minisini <gambas at ...1...>:
>
> I have created a new svn branch dedicated to the 64 bits port. I hope
> that,
> this way, I will be able to eventually backport it to the 2.0 version if
> needed.
>
> Regards,
>
> --
> Benoit Minisini
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080106/f576c555/attachment.html>

From gambas at ...1...  Sun Jan  6 20:48:18 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 6 Jan 2008 20:48:18 +0100
Subject: [Gambas-devel] New branch for 64 bits development
In-Reply-To: <8eb28a500801061145h5b3d218ao17a3670eaf508b26@...178...>
References: <200801062002.23288.gambas@...1...>
	<8eb28a500801061145h5b3d218ao17a3670eaf508b26@...178...>
Message-ID: <200801062048.18954.gambas@...1...>

On dimanche 6 janvier 2008, Jos? Luis Redrejo wrote:
> You're great Beno?t, but an idea is around my mind for the last days: you
> deserve a rest after the 2.0 release, haven't you felt the need to unplug
> every computer for some days and doing just nothing?
> Don't misunderstand me: I'm happy seeing your advances everyday, but I'm
> beginning to think you're not human ;-)
>
> Cheers.
> Jos? L.
>

Not really human. But I admit I may unplug a little, I have a lot of vacation 
to take :-)

-- 
Benoit Minisini



From lordheavym at ...176...  Sun Jan  6 21:51:54 2008
From: lordheavym at ...176... (Laurent Carlier)
Date: Sun, 6 Jan 2008 21:51:54 +0100
Subject: [Gambas-devel] Build failed for Gambas 2.0.0
In-Reply-To: <200801051226.09033.gambas@...1...>
References: <200801032003.39326.gambas@...538...>
	<200801051226.09033.gambas@...1...>
Message-ID: <200801062151.59288.lordheavym@...176...>

Le Saturday 05 January 2008 12:26:08 Benoit Minisini, vous avez ?crit?:
>
> I have modified some little things in the X11 detection code. Could you
> checkout the 3.0 trunk and test it on your system? You don't have to
> compile everything, just one X11 component like gb.desktop.
>

X11 detection code works better on openbsd with gb.sdl component, now it is 
able to detect libcursor. So it seem good for me :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080106/63b282c8/attachment.sig>

From gambas at ...538...  Mon Jan  7 16:35:40 2008
From: gambas at ...538... (manuel viet)
Date: Mon, 7 Jan 2008 07:35:40 -0800 (PST)
Subject: [Gambas-devel] Build failed for Gambas 2.0.0
In-Reply-To: <200801051226.09033.gambas@...1...>
References: <200801032003.39326.gambas@...538...>
	<200801051226.09033.gambas@...1...>
Message-ID: <14668386.post@...565...>



Benoit Minisini wrote:
> 
> 
> I have modified some little things in the X11 detection code. Could you 
> checkout the 3.0 trunk and test it on your system? You don't have to
> compile 
> everything, just one X11 component like gb.desktop.
> 
> 
Hello,

I tried to send you an answer but it has not shown up yesterday,
so I'm pasting it here :

? Well, I tried on my current setup, but my autotools are hopelessly out of
date 
too, and I couldn't reconf the trunk. I think I will throw the towel at this 
point, and probably install a whole up to date system before going on. Sorry 
I couldn't help more. ?

As an afterthought, it might be a good idea that ./configure explicitely
tells
the user that failling to build gb.desktop will forbid the IDE to run at all
?
Maybe, even better, disabling the whole IDE in that case, and telling that
make will only build the runtime ? Just a thought.

Cheers,

-----
-- 
Manuel Viet
-- 
View this message in context: http://www.nabble.com/Build-failed-for-Gambas-2.0.0-tp14603092p14668386.html
Sent from the gambas-devel mailing list archive at Nabble.com.




From jredrejo at ...176...  Wed Jan  9 20:32:46 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Wed, 9 Jan 2008 20:32:46 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801092021.29576.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<8eb28a500801091104s415eb37ev9069b74810e9e854@...178...>
	<200801092021.29576.gambas@...1...>
Message-ID: <8eb28a500801091132m600b8374j5e3fc7d2cdfed727@...178...>

2008/1/9, Benoit Minisini <gambas at ...1...>:
>
> On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > Ok, First try on a 64 bits amd system.
> >
> > svn revision 936,
> >
> > executed
> > ./reconf-all
> > ./configure --prefix=/usr
> >
> > Only some libraries installed so, configure final output was:
> > THESE COMPONENTS ARE DISABLED:
> >
> > - gb.compress.bzlib2
> > - gb.corba
> > - gb.db.firebird
> > - gb.db.mysql
> > - gb.db.odbc
> > - gb.db.postgresql
> > - gb.db.sqlite2
> > - gb.db.sqlite3
> > - gb.gtk.svg
> > - gb.net.curl
> > - gb.opengl
> > - gb.pcre
> > - gb.pdf
> > - gb.qt
> > - gb.qt.kde
> > - gb.qte
> > - gb.sdl
> > - gb.sdl.sound
> >
> > ************************************************************
> >
> >
> > The compilation failed pretty soon, I've copied the whole process in the
> > attached file.
> > I guess you don't need it, but, anyway, config.log is attached too.
> >
> > Regards.
> > Jos? L.
> >
>
> Thanks. Send the result on the developer mailing-list instead, and it will
> be
> perfect :-)



uops, fixed :-D


You can try rev. 939 now!
>


Done, log attached as before.
Regards.
Jos? L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080109/6a306aa6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambas64bits-r939.log
Type: text/x-log
Size: 33482 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080109/6a306aa6/attachment.bin>

From gambas at ...1...  Wed Jan  9 21:32:58 2008
From: gambas at ...1... (Benoit Minisini)
Date: Wed, 9 Jan 2008 21:32:58 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801091132m600b8374j5e3fc7d2cdfed727@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801092021.29576.gambas@...1...>
	<8eb28a500801091132m600b8374j5e3fc7d2cdfed727@...178...>
Message-ID: <200801092132.58765.gambas@...1...>

On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> Done, log attached as before.
> Regards.
> Jos? L.

You can try rev 641 now...

-- 
Benoit Minisini



From gambas at ...1...  Wed Jan  9 21:33:55 2008
From: gambas at ...1... (Benoit Minisini)
Date: Wed, 9 Jan 2008 21:33:55 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801092132.58765.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<8eb28a500801091132m600b8374j5e3fc7d2cdfed727@...178...>
	<200801092132.58765.gambas@...1...>
Message-ID: <200801092133.55198.gambas@...1...>

On mercredi 9 janvier 2008, Benoit Minisini wrote:
> On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > Done, log attached as before.
> > Regards.
> > Jos? L.
>
> You can try rev 641 now...

I mean 941 of course!

-- 
Benoit Minisini



From jredrejo at ...176...  Wed Jan  9 21:46:59 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Wed, 9 Jan 2008 21:46:59 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801092133.55198.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<8eb28a500801091132m600b8374j5e3fc7d2cdfed727@...178...>
	<200801092132.58765.gambas@...1...>
	<200801092133.55198.gambas@...1...>
Message-ID: <8eb28a500801091246u460311afoaeb62a7ec3d5f9ec@...178...>

2008/1/9, Benoit Minisini <gambas at ...1...>:
>
> On mercredi 9 janvier 2008, Benoit Minisini wrote:
> > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > Done, log attached as before.
> > > Regards.
> > > Jos? L.
> >
> > You can try rev 641 now...
>
> I mean 941 of course!
>
> -


Here it goes..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080109/abb6790e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambas64bits-r941.log
Type: text/x-log
Size: 22956 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080109/abb6790e/attachment.bin>

From gambas at ...1...  Wed Jan  9 21:51:40 2008
From: gambas at ...1... (Benoit Minisini)
Date: Wed, 9 Jan 2008 21:51:40 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801091246u460311afoaeb62a7ec3d5f9ec@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801092133.55198.gambas@...1...>
	<8eb28a500801091246u460311afoaeb62a7ec3d5f9ec@...178...>
Message-ID: <200801092151.40719.gambas@...1...>

On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> 2008/1/9, Benoit Minisini <gambas at ...1...>:
> > On mercredi 9 janvier 2008, Benoit Minisini wrote:
> > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > Done, log attached as before.
> > > > Regards.
> > > > Jos? L.
> > >
> > > You can try rev 641 now...
> >
> > I mean 941 of course!
> >
> > -
>
> Here it goes..

Fixed!

-- 
Benoit Minisini



From jredrejo at ...176...  Wed Jan  9 23:27:24 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Wed, 9 Jan 2008 23:27:24 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801092151.40719.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801092133.55198.gambas@...1...>
	<8eb28a500801091246u460311afoaeb62a7ec3d5f9ec@...178...>
	<200801092151.40719.gambas@...1...>
Message-ID: <8eb28a500801091427i79f45dacr735f9299529f36b0@...178...>

Much better, here goes the latest for today.

Regards.
Jos? L.

2008/1/9, Benoit Minisini <gambas at ...1...>:
>
> On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > 2008/1/9, Benoit Minisini <gambas at ...1...>:
> > > On mercredi 9 janvier 2008, Benoit Minisini wrote:
> > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > Done, log attached as before.
> > > > > Regards.
> > > > > Jos? L.
> > > >
> > > > You can try rev 641 now...
> > >
> > > I mean 941 of course!
> > >
> > > -
> >
> > Here it goes..
>
> Fixed!
>
> --
> Benoit Minisini
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080109/92be1a10/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambas64bits-r942.log
Type: text/x-log
Size: 108877 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080109/92be1a10/attachment.bin>

From david_villalobos_c at ...7...  Thu Jan 10 16:39:47 2008
From: david_villalobos_c at ...7... (David Villalobos Cambronero)
Date: Thu, 10 Jan 2008 07:39:47 -0800 (PST)
Subject: [Gambas-devel] Translation for spanish
Message-ID: <475475.62857.qm@...566...>

Hi all,

For Gambas 2.0 I found some new strings... so here is the translation file... hope someone can upload it

Best regards

David




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080110/5d3baba6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Gambas2.es.po
Type: application/octet-stream
Size: 68902 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080110/5d3baba6/attachment.obj>

From gambas at ...1...  Thu Jan 10 19:27:38 2008
From: gambas at ...1... (Benoit Minisini)
Date: Thu, 10 Jan 2008 19:27:38 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801091427i79f45dacr735f9299529f36b0@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801092151.40719.gambas@...1...>
	<8eb28a500801091427i79f45dacr735f9299529f36b0@...178...>
Message-ID: <200801101927.38771.gambas@...1...>

On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> Much better, here goes the latest for today.
>
> Regards.
> Jos? L.
>

You can check the last rev.

-- 
Benoit Minisini



From gambas.fr at ...176...  Fri Jan 11 00:20:06 2008
From: gambas.fr at ...176... (Fabien Bodard)
Date: Fri, 11 Jan 2008 00:20:06 +0100
Subject: [Gambas-devel] Fwd: Re: [Gambas-user] Printing from the TextEdit
	html control
Message-ID: <200801110020.06306.gambas.fr@...176...>


----------  Message transmis  ----------

Sujet?: Re: [Gambas-user] Printing from the TextEdit html control
Date?: jeudi 10 janvier 2008
De?: richard terry <rterry at ...567...>
??: Fabien Bodard <gambas.fr at ...176...>

On Fri, 11 Jan 2008 08:55:07 am you wrote:
> lol not in the prevew form
> never touch to this form... it's a static form that is able to show you the
> report result... it's not the report
>
>
>
> Change it in the main Form
> in the button2_click sub
>
> after Report.clear

Ok, here it is

-------------------------------------------------------


 this is  bug on RichText printing
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print.pdf
Type: application/postscript
Size: 60704 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080111/ec041ea6/attachment.ai>

From tcahya at ...7...  Fri Jan 11 04:42:00 2008
From: tcahya at ...7... (Taufiq Cahyadi)
Date: Thu, 10 Jan 2008 19:42:00 -0800 (PST)
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801092132.58765.gambas@...1...>
Message-ID: <971920.93270.qm@...568...>

I have aplication with gambas2-1.9.91-1 ...and when i
compile all program it's no error ...the trouble show
up when i Make intallation package ..and show message

--------------------------------
Creating package for Mandriva Linux.
Initializing ~/RPM directory.
Creating source package.
Creating .spec file.
Creating package...

rpmbuild -ba /home/administrator/RPM/SPECS/hrd.spec
Executing(%prep): /bin/sh -e
/home/administrator/RPM/tmp/rpm-tmp.53691
+ umask 022
+ cd /home/administrator/RPM/BUILD
+ rm -rf
/home/administrator/RPM/tmp/hrd-0.0-1mdv-buildroot
+ cd /home/administrator/RPM/BUILD
+ rm -rf hrd
+ /usr/bin/bzip2 -dc
/home/administrator/RPM/SOURCES/hrd-0.0.tar.bz2
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd hrd
/home/administrator/RPM/tmp/rpm-tmp.53691: line 31:
cd: hrd: No such file or directory
error: Bad exit status from
/home/administrator/RPM/tmp/rpm-tmp.53691 (%prep)


RPM build errors:
    Bad exit status from
/home/administrator/RPM/tmp/rpm-tmp.53691 (%prep)

The package build has failed.
Package.MakeRpmPackage.781: 'rpmbuild' has returned
the following error code: 1
--------------------------------

anyone can help me ... what wrong with my program...

Thank you very much ....




      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs



From gambas at ...1...  Fri Jan 11 10:37:20 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 11 Jan 2008 10:37:20 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <971920.93270.qm@...568...>
References: <971920.93270.qm@...568...>
Message-ID: <200801111037.20297.gambas@...1...>

On vendredi 11 janvier 2008, Taufiq Cahyadi wrote:
> I have aplication with gambas2-1.9.91-1 ...and when i
> compile all program it's no error ...the trouble show
> up when i Make intallation package ..and show message
>
> --------------------------------
> Creating package for Mandriva Linux.
> Initializing ~/RPM directory.
> Creating source package.
> Creating .spec file.
> Creating package...
>
> rpmbuild -ba /home/administrator/RPM/SPECS/hrd.spec
> Executing(%prep): /bin/sh -e
> /home/administrator/RPM/tmp/rpm-tmp.53691
> + umask 022
> + cd /home/administrator/RPM/BUILD
> + rm -rf
> /home/administrator/RPM/tmp/hrd-0.0-1mdv-buildroot
> + cd /home/administrator/RPM/BUILD
> + rm -rf hrd
> + /usr/bin/bzip2 -dc
> /home/administrator/RPM/SOURCES/hrd-0.0.tar.bz2
> + tar -xf -
> + STATUS=0
> + '[' 0 -ne 0 ']'
> + cd hrd
> /home/administrator/RPM/tmp/rpm-tmp.53691: line 31:
> cd: hrd: No such file or directory
> error: Bad exit status from
> /home/administrator/RPM/tmp/rpm-tmp.53691 (%prep)
>
>
> RPM build errors:
>     Bad exit status from
> /home/administrator/RPM/tmp/rpm-tmp.53691 (%prep)
>
> The package build has failed.
> Package.MakeRpmPackage.781: 'rpmbuild' has returned
> the following error code: 1
> --------------------------------
>
> anyone can help me ... what wrong with my program...
>
> Thank you very much ....
>

Can you try the final 2.0 version?

-- 
Benoit Minisini



From gambas at ...1...  Fri Jan 11 10:42:53 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 11 Jan 2008 10:42:53 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <971920.93270.qm@...568...>
References: <971920.93270.qm@...568...>
Message-ID: <200801111042.54053.gambas@...1...>

On vendredi 11 janvier 2008, Taufiq Cahyadi wrote:
> I have aplication with gambas2-1.9.91-1 ...and when i
> compile all program it's no error ...the trouble show
> up when i Make intallation package ..and show message
>
> --------------------------------
> Creating package for Mandriva Linux.
> Initializing ~/RPM directory.
> Creating source package.
> Creating .spec file.
> Creating package...
>
> rpmbuild -ba /home/administrator/RPM/SPECS/hrd.spec
> Executing(%prep): /bin/sh -e
> /home/administrator/RPM/tmp/rpm-tmp.53691
> + umask 022
> + cd /home/administrator/RPM/BUILD
> + rm -rf
> /home/administrator/RPM/tmp/hrd-0.0-1mdv-buildroot
> + cd /home/administrator/RPM/BUILD
> + rm -rf hrd
> + /usr/bin/bzip2 -dc
> /home/administrator/RPM/SOURCES/hrd-0.0.tar.bz2
> + tar -xf -
> + STATUS=0
> + '[' 0 -ne 0 ']'
> + cd hrd
> /home/administrator/RPM/tmp/rpm-tmp.53691: line 31:
> cd: hrd: No such file or directory
> error: Bad exit status from
> /home/administrator/RPM/tmp/rpm-tmp.53691 (%prep)
>
>
> RPM build errors:
>     Bad exit status from
> /home/administrator/RPM/tmp/rpm-tmp.53691 (%prep)
>
> The package build has failed.
> Package.MakeRpmPackage.781: 'rpmbuild' has returned
> the following error code: 1
> --------------------------------
>
> anyone can help me ... what wrong with my program...
>
> Thank you very much ....
>

And next time, please post your question:
- On the right mailing-list.
- On the right thread.
- With the right subject.

Thanks!

-- 
Benoit Minisini



From jredrejo at ...176...  Fri Jan 11 12:10:31 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Fri, 11 Jan 2008 12:10:31 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801101927.38771.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801092151.40719.gambas@...1...>
	<8eb28a500801091427i79f45dacr735f9299529f36b0@...178...>
	<200801101927.38771.gambas@...1...>
Message-ID: <8eb28a500801110310kbbc4f5bl96a323058da9bd8a@...178...>

2008/1/10, Benoit Minisini <gambas at ...1...>:
>
> On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > Much better, here goes the latest for today.
> >
> > Regards.
> > Jos? L.
> >
>
> You can check the last rev.
>
>
Result of rev 946 attached
Regards.
Jos? L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080111/3861b798/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambas64bits-r946.log
Type: text/x-log
Size: 191128 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080111/3861b798/attachment.bin>

From gambas at ...1...  Fri Jan 11 12:50:12 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 11 Jan 2008 12:50:12 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801110310kbbc4f5bl96a323058da9bd8a@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801101927.38771.gambas@...1...>
	<8eb28a500801110310kbbc4f5bl96a323058da9bd8a@...178...>
Message-ID: <200801111250.12946.gambas@...1...>

On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > Much better, here goes the latest for today.
> > >
> > > Regards.
> > > Jos? L.
> >
> > You can check the last rev.
>
> Result of rev 946 attached
> Regards.
> Jos? L.

Fixed in rev. 947. 

Beware, everything will be recompiled because of a fix in gambas.h.

Regards,

-- 
Benoit Minisini



From jredrejo at ...176...  Fri Jan 11 13:32:00 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Fri, 11 Jan 2008 13:32:00 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801111250.12946.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801101927.38771.gambas@...1...>
	<8eb28a500801110310kbbc4f5bl96a323058da9bd8a@...178...>
	<200801111250.12946.gambas@...1...>
Message-ID: <8eb28a500801110432t73448042o397c43d769c8afe6@...178...>

2008/1/11, Benoit Minisini <gambas at ...1...>:
>
> On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > Much better, here goes the latest for today.
> > > >
> > > > Regards.
> > > > Jos? L.
> > >
> > > You can check the last rev.
> >
> > Result of rev 946 attached
> > Regards.
> > Jos? L.
>
> Fixed in rev. 947.
>
> Beware, everything will be recompiled because of a fix in gambas.h.
>
>
I always do a make clean before compiling, and reconf-all & configure if you
change any autotols related file.
New compilation attached.

Jos? L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080111/bb85b79c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambas64bits-r947.log
Type: text/x-log
Size: 194790 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080111/bb85b79c/attachment.bin>

From gambas at ...1...  Fri Jan 11 13:43:31 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 11 Jan 2008 13:43:31 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801110432t73448042o397c43d769c8afe6@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801111250.12946.gambas@...1...>
	<8eb28a500801110432t73448042o397c43d769c8afe6@...178...>
Message-ID: <200801111343.31764.gambas@...1...>

On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > Much better, here goes the latest for today.
> > > > >
> > > > > Regards.
> > > > > Jos? L.
> > > >
> > > > You can check the last rev.
> > >
> > > Result of rev 946 attached
> > > Regards.
> > > Jos? L.
> >
> > Fixed in rev. 947.
> >
> > Beware, everything will be recompiled because of a fix in gambas.h.
>
> I always do a make clean before compiling, and reconf-all & configure if
> you change any autotols related file.
> New compilation attached.
>
> Jos? L.

Fixed in rev. 948. You don't have to reconf and make clean if you can.

Regards,

-- 
Benoit Minisini



From jredrejo at ...176...  Sat Jan 12 10:16:30 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Sat, 12 Jan 2008 10:16:30 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801111343.31764.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801111250.12946.gambas@...1...>
	<8eb28a500801110432t73448042o397c43d769c8afe6@...178...>
	<200801111343.31764.gambas@...1...>
Message-ID: <8eb28a500801120116u24125a42p69db6ea0f847f38@...178...>

2008/1/11, Benoit Minisini <gambas at ...1...>:
>
> On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > Much better, here goes the latest for today.
> > > > > >
> > > > > > Regards.
> > > > > > Jos? L.
> > > > >
> > > > > You can check the last rev.
> > > >
> > > > Result of rev 946 attached
> > > > Regards.
> > > > Jos? L.
> > >
> > > Fixed in rev. 947.
> > >
> > > Beware, everything will be recompiled because of a fix in gambas.h.
> >
> > I always do a make clean before compiling, and reconf-all & configure if
> > you change any autotols related file.
> > New compilation attached.
> >
> > Jos? L.
>
> Fixed in rev. 948. You don't have to reconf and make clean if you can.
>
> Regards,
>
>
Attached result of compiling revision 951. As the compilation didn't fail, I
tried a make install, and you can see as the informer segfaults with gb.gtk.


Regards.
Jos? L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080112/ff71c0d4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambas64bits-r951.log
Type: text/x-log
Size: 292557 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080112/ff71c0d4/attachment.bin>

From gambas at ...1...  Sat Jan 12 13:19:42 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sat, 12 Jan 2008 13:19:42 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801120116u24125a42p69db6ea0f847f38@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801111343.31764.gambas@...1...>
	<8eb28a500801120116u24125a42p69db6ea0f847f38@...178...>
Message-ID: <200801121319.42322.gambas@...1...>

On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > > > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > Much better, here goes the latest for today.
> > > > > > >
> > > > > > > Regards.
> > > > > > > Jos? L.
> > > > > >
> > > > > > You can check the last rev.
> > > > >
> > > > > Result of rev 946 attached
> > > > > Regards.
> > > > > Jos? L.
> > > >
> > > > Fixed in rev. 947.
> > > >
> > > > Beware, everything will be recompiled because of a fix in gambas.h.
> > >
> > > I always do a make clean before compiling, and reconf-all & configure
> > > if you change any autotols related file.
> > > New compilation attached.
> > >
> > > Jos? L.
> >
> > Fixed in rev. 948. You don't have to reconf and make clean if you can.
> >
> > Regards,
>
> Attached result of compiling revision 951. As the compilation didn't fail,
> I tried a make install, and you can see as the informer segfaults with
> gb.gtk.
>
>
> Regards.
> Jos? L.

No way you get a backtrace?

-- 
Benoit Minisini



From jredrejo at ...176...  Sat Jan 12 13:51:38 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Sat, 12 Jan 2008 13:51:38 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801121319.42322.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801111343.31764.gambas@...1...>
	<8eb28a500801120116u24125a42p69db6ea0f847f38@...178...>
	<200801121319.42322.gambas@...1...>
Message-ID: <8eb28a500801120451g9c1f27ge539e7e788a22106@...178...>

2008/1/12, Benoit Minisini <gambas at ...1...>:
>
> On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > > > > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > Much better, here goes the latest for today.
> > > > > > > >
> > > > > > > > Regards.
> > > > > > > > Jos? L.
> > > > > > >
> > > > > > > You can check the last rev.
> > > > > >
> > > > > > Result of rev 946 attached
> > > > > > Regards.
> > > > > > Jos? L.
> > > > >
> > > > > Fixed in rev. 947.
> > > > >
> > > > > Beware, everything will be recompiled because of a fix in gambas.h
> .
> > > >
> > > > I always do a make clean before compiling, and reconf-all &
> configure
> > > > if you change any autotols related file.
> > > > New compilation attached.
> > > >
> > > > Jos? L.
> > >
> > > Fixed in rev. 948. You don't have to reconf and make clean if you can.
> > >
> > > Regards,
> >
> > Attached result of compiling revision 951. As the compilation didn't
> fail,
> > I tried a make install, and you can see as the informer segfaults with
> > gb.gtk.
> >
> >
> > Regards.
> > Jos? L.
>
> No way you get a backtrace?



This is what I've got, I don't have a deep knowledge of gdb, so I suspect
I'm missing some option:

(sid_amd64)jredrejo at ...569...:~/64bits$ gdb
/home/jredrejo/64bits/debian/bin/gbi3
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) set args -p -r /home/jredrejo/64bits/debian/
(gdb) run
Starting program: /home/jredrejo/64bits/debian/bin/gbi3 -p -r
/home/jredrejo/64bits/debian/
gb.debug
gb.eval
gb.db
gb.compress
gb.vb
gb.option
gb.gui
gbi3: warning: component gb.qt not found
gb
gb.gtk.ext
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) bt
#0  0x00002ae943f9710e in ?? () from /lib64/ld-linux-x86-64.so.2
#1  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x00002ae943f9691b in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x00002ae9441a3f8b in ?? () from /lib/libdl.so.2
#4  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x00002ae9441a44ed in ?? () from /lib/libdl.so.2
#6  0x00002ae9441a3ef1 in dlopen () from /lib/libdl.so.2
#7  0x000000000040378b in analyze (comp=<value optimized out>, include=0
'\0') at gbi.c:377
#8  0x0000000000403e1f in main (argc=4, argv=<value optimized out>) at gbi.c
:655
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080112/45475612/attachment.html>

From gambas at ...1...  Sat Jan 12 14:27:41 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sat, 12 Jan 2008 14:27:41 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801120451g9c1f27ge539e7e788a22106@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801121319.42322.gambas@...1...>
	<8eb28a500801120451g9c1f27ge539e7e788a22106@...178...>
Message-ID: <200801121427.41310.gambas@...1...>

On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> 2008/1/12, Benoit Minisini <gambas at ...1...>:
> > On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > > > > > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > > Much better, here goes the latest for today.
> > > > > > > > >
> > > > > > > > > Regards.
> > > > > > > > > Jos? L.
> > > > > > > >
> > > > > > > > You can check the last rev.
> > > > > > >
> > > > > > > Result of rev 946 attached
> > > > > > > Regards.
> > > > > > > Jos? L.
> > > > > >
> > > > > > Fixed in rev. 947.
> > > > > >
> > > > > > Beware, everything will be recompiled because of a fix in
> > > > > > gambas.h
> >
> > .
> >
> > > > > I always do a make clean before compiling, and reconf-all &
> >
> > configure
> >
> > > > > if you change any autotols related file.
> > > > > New compilation attached.
> > > > >
> > > > > Jos? L.
> > > >
> > > > Fixed in rev. 948. You don't have to reconf and make clean if you
> > > > can.
> > > >
> > > > Regards,
> > >
> > > Attached result of compiling revision 951. As the compilation didn't
> >
> > fail,
> >
> > > I tried a make install, and you can see as the informer segfaults with
> > > gb.gtk.
> > >
> > >
> > > Regards.
> > > Jos? L.
> >
> > No way you get a backtrace?
>
> This is what I've got, I don't have a deep knowledge of gdb, so I suspect
> I'm missing some option:
>
> (sid_amd64)jredrejo at ...569...:~/64bits$ gdb
> /home/jredrejo/64bits/debian/bin/gbi3
> GNU gdb 6.7.1-debian
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html
>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu"...
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) set args -p -r /home/jredrejo/64bits/debian/
> (gdb) run
> Starting program: /home/jredrejo/64bits/debian/bin/gbi3 -p -r
> /home/jredrejo/64bits/debian/
> gb.debug
> gb.eval
> gb.db
> gb.compress
> gb.vb
> gb.option
> gb.gui
> gbi3: warning: component gb.qt not found
> gb
> gb.gtk.ext
> [Thread debugging using libthread_db enabled]
> Error while reading shared library symbols:
> Cannot find new threads: generic error
> Cannot find new threads: generic error
> (gdb) bt
> #0  0x00002ae943f9710e in ?? () from /lib64/ld-linux-x86-64.so.2
> #1  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> #2  0x00002ae943f9691b in ?? () from /lib64/ld-linux-x86-64.so.2
> #3  0x00002ae9441a3f8b in ?? () from /lib/libdl.so.2
> #4  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> #5  0x00002ae9441a44ed in ?? () from /lib/libdl.so.2
> #6  0x00002ae9441a3ef1 in dlopen () from /lib/libdl.so.2
> #7  0x000000000040378b in analyze (comp=<value optimized out>, include=0
> '\0') at gbi.c:377
> #8  0x0000000000403e1f in main (argc=4, argv=<value optimized out>) at
> gbi.c
>
> :655

Some crash inside dlopen? Weird...

First you should compile without optimizations:

$ make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g"

Then to trace gbi3:

$ gdb gbi3
...
(gdb) run -p -r /home/jredrejo/64bits/debian/ gb.gtk
...

Regards,

-- 
Benoit Minisini



From jredrejo at ...176...  Sat Jan 12 16:04:02 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Sat, 12 Jan 2008 16:04:02 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801121427.41310.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801121319.42322.gambas@...1...>
	<8eb28a500801120451g9c1f27ge539e7e788a22106@...178...>
	<200801121427.41310.gambas@...1...>
Message-ID: <8eb28a500801120704p978eb1cqdd6eed9bf2d12f94@...178...>

2008/1/12, Benoit Minisini <gambas at ...1...>:
>
> On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > 2008/1/12, Benoit Minisini <gambas at ...1...>:
> > > On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > > > > > > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > > > Much better, here goes the latest for today.
> > > > > > > > > >
> > > > > > > > > > Regards.
> > > > > > > > > > Jos? L.
> > > > > > > > >
> > > > > > > > > You can check the last rev.
> > > > > > > >
> > > > > > > > Result of rev 946 attached
> > > > > > > > Regards.
> > > > > > > > Jos? L.
> > > > > > >
> > > > > > > Fixed in rev. 947.
> > > > > > >
> > > > > > > Beware, everything will be recompiled because of a fix in
> > > > > > > gambas.h
> > >
> > > .
> > >
> > > > > > I always do a make clean before compiling, and reconf-all &
> > >
> > > configure
> > >
> > > > > > if you change any autotols related file.
> > > > > > New compilation attached.
> > > > > >
> > > > > > Jos? L.
> > > > >
> > > > > Fixed in rev. 948. You don't have to reconf and make clean if you
> > > > > can.
> > > > >
> > > > > Regards,
> > > >
> > > > Attached result of compiling revision 951. As the compilation didn't
> > >
> > > fail,
> > >
> > > > I tried a make install, and you can see as the informer segfaults
> with
> > > > gb.gtk.
> > > >
> > > >
> > > > Regards.
> > > > Jos? L.
> > >
> > > No way you get a backtrace?
> >
> > This is what I've got, I don't have a deep knowledge of gdb, so I
> suspect
> > I'm missing some option:
> >
> > (sid_amd64)jredrejo at ...569...:~/64bits$ gdb
> > /home/jredrejo/64bits/debian/bin/gbi3
> > GNU gdb 6.7.1-debian
> > Copyright (C) 2007 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html
> >
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu"...
> > Using host libthread_db library "/lib/libthread_db.so.1".
> > (gdb) set args -p -r /home/jredrejo/64bits/debian/
> > (gdb) run
> > Starting program: /home/jredrejo/64bits/debian/bin/gbi3 -p -r
> > /home/jredrejo/64bits/debian/
> > gb.debug
> > gb.eval
> > gb.db
> > gb.compress
> > gb.vb
> > gb.option
> > gb.gui
> > gbi3: warning: component gb.qt not found
> > gb
> > gb.gtk.ext
> > [Thread debugging using libthread_db enabled]
> > Error while reading shared library symbols:
> > Cannot find new threads: generic error
> > Cannot find new threads: generic error
> > (gdb) bt
> > #0  0x00002ae943f9710e in ?? () from /lib64/ld-linux-x86-64.so.2
> > #1  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> > #2  0x00002ae943f9691b in ?? () from /lib64/ld-linux-x86-64.so.2
> > #3  0x00002ae9441a3f8b in ?? () from /lib/libdl.so.2
> > #4  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> > #5  0x00002ae9441a44ed in ?? () from /lib/libdl.so.2
> > #6  0x00002ae9441a3ef1 in dlopen () from /lib/libdl.so.2
> > #7  0x000000000040378b in analyze (comp=<value optimized out>, include=0
> > '\0') at gbi.c:377
> > #8  0x0000000000403e1f in main (argc=4, argv=<value optimized out>) at
> > gbi.c
> >
> > :655
>
> Some crash inside dlopen? Weird...
>
> First you should compile without optimizations:
>
> $ make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g"
>
> Then to trace gbi3:
>
> $ gdb gbi3
> ...
> (gdb) run -p -r /home/jredrejo/64bits/debian/ gb.gtk
> ...
>



No much difference:
(sid_amd64)jredrejo at ...569...:~/64bits$ gdb
/home/jredrejo/64bits/debian/bin/gbi3
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -p -r /home/jredrejo/64bits/debian/ gb.gtk
Starting program: /home/jredrejo/64bits/debian/bin/gbi3 -p -r
/home/jredrejo/64bits/debian/ gb.gtk
gb.gtk
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) bt
#0  0x00002add4832810e in ?? () from /lib64/ld-linux-x86-64.so.2
#1  0x00002add48323df6 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x00002add4832791b in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x00002add48534f8b in ?? () from /lib/libdl.so.2
#4  0x00002add48323df6 in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x00002add485354ed in ?? () from /lib/libdl.so.2
#6  0x00002add48534ef1 in dlopen () from /lib/libdl.so.2
#7  0x00000000004054b0 in analyze_native_component (path=0x609420
"/home/jredrejo/64bits/debian/lib/gambas3/gb.gtk.so")
    at gbi.c:377
#8  0x00000000004059d1 in analyze (comp=0x7fff62792bf8 "gb.gtk", include=0
'\0') at gbi.c:520
#9  0x0000000000405cde in main (argc=5, argv=0x7fff62791178) at gbi.c:678
(gdb)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080112/db26a85b/attachment.html>

From gambas at ...1...  Sat Jan 12 16:09:03 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sat, 12 Jan 2008 16:09:03 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801120704p978eb1cqdd6eed9bf2d12f94@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801121427.41310.gambas@...1...>
	<8eb28a500801120704p978eb1cqdd6eed9bf2d12f94@...178...>
Message-ID: <200801121609.03943.gambas@...1...>

On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> 2008/1/12, Benoit Minisini <gambas at ...1...>:
> > On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > > 2008/1/12, Benoit Minisini <gambas at ...1...>:
> > > > On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > > > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > > 2008/1/10, Benoit Minisini <gambas at ...1...>:
> > > > > > > > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > > > > Much better, here goes the latest for today.
> > > > > > > > > > >
> > > > > > > > > > > Regards.
> > > > > > > > > > > Jos? L.
> > > > > > > > > >
> > > > > > > > > > You can check the last rev.
> > > > > > > > >
> > > > > > > > > Result of rev 946 attached
> > > > > > > > > Regards.
> > > > > > > > > Jos? L.
> > > > > > > >
> > > > > > > > Fixed in rev. 947.
> > > > > > > >
> > > > > > > > Beware, everything will be recompiled because of a fix in
> > > > > > > > gambas.h
> > > >
> > > > .
> > > >
> > > > > > > I always do a make clean before compiling, and reconf-all &
> > > >
> > > > configure
> > > >
> > > > > > > if you change any autotols related file.
> > > > > > > New compilation attached.
> > > > > > >
> > > > > > > Jos? L.
> > > > > >
> > > > > > Fixed in rev. 948. You don't have to reconf and make clean if you
> > > > > > can.
> > > > > >
> > > > > > Regards,
> > > > >
> > > > > Attached result of compiling revision 951. As the compilation
> > > > > didn't
> > > >
> > > > fail,
> > > >
> > > > > I tried a make install, and you can see as the informer segfaults
> >
> > with
> >
> > > > > gb.gtk.
> > > > >
> > > > >
> > > > > Regards.
> > > > > Jos? L.
> > > >
> > > > No way you get a backtrace?
> > >
> > > This is what I've got, I don't have a deep knowledge of gdb, so I
> >
> > suspect
> >
> > > I'm missing some option:
> > >
> > > (sid_amd64)jredrejo at ...569...:~/64bits$ gdb
> > > /home/jredrejo/64bits/debian/bin/gbi3
> > > GNU gdb 6.7.1-debian
> > > Copyright (C) 2007 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later
> > > <http://gnu.org/licenses/gpl.html
> > >
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.  Type "show
> >
> > copying"
> >
> > > and "show warranty" for details.
> > > This GDB was configured as "x86_64-linux-gnu"...
> > > Using host libthread_db library "/lib/libthread_db.so.1".
> > > (gdb) set args -p -r /home/jredrejo/64bits/debian/
> > > (gdb) run
> > > Starting program: /home/jredrejo/64bits/debian/bin/gbi3 -p -r
> > > /home/jredrejo/64bits/debian/
> > > gb.debug
> > > gb.eval
> > > gb.db
> > > gb.compress
> > > gb.vb
> > > gb.option
> > > gb.gui
> > > gbi3: warning: component gb.qt not found
> > > gb
> > > gb.gtk.ext
> > > [Thread debugging using libthread_db enabled]
> > > Error while reading shared library symbols:
> > > Cannot find new threads: generic error
> > > Cannot find new threads: generic error
> > > (gdb) bt
> > > #0  0x00002ae943f9710e in ?? () from /lib64/ld-linux-x86-64.so.2
> > > #1  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> > > #2  0x00002ae943f9691b in ?? () from /lib64/ld-linux-x86-64.so.2
> > > #3  0x00002ae9441a3f8b in ?? () from /lib/libdl.so.2
> > > #4  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> > > #5  0x00002ae9441a44ed in ?? () from /lib/libdl.so.2
> > > #6  0x00002ae9441a3ef1 in dlopen () from /lib/libdl.so.2
> > > #7  0x000000000040378b in analyze (comp=<value optimized out>,
> > > include=0 '\0') at gbi.c:377
> > > #8  0x0000000000403e1f in main (argc=4, argv=<value optimized out>) at
> > > gbi.c
> > >
> > > :655
> >
> > Some crash inside dlopen? Weird...
> >
> > First you should compile without optimizations:
> >
> > $ make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g"
> >
> > Then to trace gbi3:
> >
> > $ gdb gbi3
> > ...
> > (gdb) run -p -r /home/jredrejo/64bits/debian/ gb.gtk
> > ...
>
> No much difference:
> (sid_amd64)jredrejo at ...569...:~/64bits$ gdb
> /home/jredrejo/64bits/debian/bin/gbi3
> GNU gdb 6.7.1-debian
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html
>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu"...
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) run -p -r /home/jredrejo/64bits/debian/ gb.gtk
> Starting program: /home/jredrejo/64bits/debian/bin/gbi3 -p -r
> /home/jredrejo/64bits/debian/ gb.gtk
> gb.gtk
> [Thread debugging using libthread_db enabled]
> Error while reading shared library symbols:
> Cannot find new threads: generic error
> Cannot find new threads: generic error
> (gdb) bt
> #0  0x00002add4832810e in ?? () from /lib64/ld-linux-x86-64.so.2
> #1  0x00002add48323df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> #2  0x00002add4832791b in ?? () from /lib64/ld-linux-x86-64.so.2
> #3  0x00002add48534f8b in ?? () from /lib/libdl.so.2
> #4  0x00002add48323df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> #5  0x00002add485354ed in ?? () from /lib/libdl.so.2
> #6  0x00002add48534ef1 in dlopen () from /lib/libdl.so.2
> #7  0x00000000004054b0 in analyze_native_component (path=0x609420
> "/home/jredrejo/64bits/debian/lib/gambas3/gb.gtk.so")
>     at gbi.c:377
> #8  0x00000000004059d1 in analyze (comp=0x7fff62792bf8 "gb.gtk", include=0
> '\0') at gbi.c:520
> #9  0x0000000000405cde in main (argc=5, argv=0x7fff62791178) at gbi.c:678
> (gdb)

Do you know why there is no "segmentation fault" message? What is this "Error 
while reading shared library symbols" error? Is it a bug in gdb? Or 
apparently the shared library is corrupted, or unreadable by gdb.

I have no idea about this problem at the moment... A crash inside dlopen() may 
be a bug in it. I will wait for the compilation of gb.qt to see if there is 
the same problem (The qt library is preloaded contratry the GTK+ library).

Regards,

-- 
Benoit Minisini



From jredrejo at ...176...  Sat Jan 12 16:11:21 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Sat, 12 Jan 2008 16:11:21 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801121609.03943.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801121427.41310.gambas@...1...>
	<8eb28a500801120704p978eb1cqdd6eed9bf2d12f94@...178...>
	<200801121609.03943.gambas@...1...>
Message-ID: <8eb28a500801120711m1b592c17q2d1f888387a11194@...178...>

2008/1/12, Benoit Minisini <gambas at ...1...>:
>
> On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > 2008/1/12, Benoit Minisini <gambas at ...1...>:
> > > On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > > > 2008/1/12, Benoit Minisini <gambas at ...1...>:
> > > > > On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > 2008/1/11, Benoit Minisini <gambas at ...1...>:
> > > > > > > > > On vendredi 11 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > > > 2008/1/10, Benoit Minisini <gambas at ...1...
> >:
> > > > > > > > > > > On mercredi 9 janvier 2008, Jos? Luis Redrejo wrote:
> > > > > > > > > > > > Much better, here goes the latest for today.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards.
> > > > > > > > > > > > Jos? L.
> > > > > > > > > > >
> > > > > > > > > > > You can check the last rev.
> > > > > > > > > >
> > > > > > > > > > Result of rev 946 attached
> > > > > > > > > > Regards.
> > > > > > > > > > Jos? L.
> > > > > > > > >
> > > > > > > > > Fixed in rev. 947.
> > > > > > > > >
> > > > > > > > > Beware, everything will be recompiled because of a fix in
> > > > > > > > > gambas.h
> > > > >
> > > > > .
> > > > >
> > > > > > > > I always do a make clean before compiling, and reconf-all &
> > > > >
> > > > > configure
> > > > >
> > > > > > > > if you change any autotols related file.
> > > > > > > > New compilation attached.
> > > > > > > >
> > > > > > > > Jos? L.
> > > > > > >
> > > > > > > Fixed in rev. 948. You don't have to reconf and make clean if
> you
> > > > > > > can.
> > > > > > >
> > > > > > > Regards,
> > > > > >
> > > > > > Attached result of compiling revision 951. As the compilation
> > > > > > didn't
> > > > >
> > > > > fail,
> > > > >
> > > > > > I tried a make install, and you can see as the informer
> segfaults
> > >
> > > with
> > >
> > > > > > gb.gtk.
> > > > > >
> > > > > >
> > > > > > Regards.
> > > > > > Jos? L.
> > > > >
> > > > > No way you get a backtrace?
> > > >
> > > > This is what I've got, I don't have a deep knowledge of gdb, so I
> > >
> > > suspect
> > >
> > > > I'm missing some option:
> > > >
> > > > (sid_amd64)jredrejo at ...569...:~/64bits$ gdb
> > > > /home/jredrejo/64bits/debian/bin/gbi3
> > > > GNU gdb 6.7.1-debian
> > > > Copyright (C) 2007 Free Software Foundation, Inc.
> > > > License GPLv3+: GNU GPL version 3 or later
> > > > <http://gnu.org/licenses/gpl.html
> > > >
> > > > This is free software: you are free to change and redistribute it.
> > > > There is NO WARRANTY, to the extent permitted by law.  Type "show
> > >
> > > copying"
> > >
> > > > and "show warranty" for details.
> > > > This GDB was configured as "x86_64-linux-gnu"...
> > > > Using host libthread_db library "/lib/libthread_db.so.1".
> > > > (gdb) set args -p -r /home/jredrejo/64bits/debian/
> > > > (gdb) run
> > > > Starting program: /home/jredrejo/64bits/debian/bin/gbi3 -p -r
> > > > /home/jredrejo/64bits/debian/
> > > > gb.debug
> > > > gb.eval
> > > > gb.db
> > > > gb.compress
> > > > gb.vb
> > > > gb.option
> > > > gb.gui
> > > > gbi3: warning: component gb.qt not found
> > > > gb
> > > > gb.gtk.ext
> > > > [Thread debugging using libthread_db enabled]
> > > > Error while reading shared library symbols:
> > > > Cannot find new threads: generic error
> > > > Cannot find new threads: generic error
> > > > (gdb) bt
> > > > #0  0x00002ae943f9710e in ?? () from /lib64/ld-linux-x86-64.so.2
> > > > #1  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> > > > #2  0x00002ae943f9691b in ?? () from /lib64/ld-linux-x86-64.so.2
> > > > #3  0x00002ae9441a3f8b in ?? () from /lib/libdl.so.2
> > > > #4  0x00002ae943f92df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> > > > #5  0x00002ae9441a44ed in ?? () from /lib/libdl.so.2
> > > > #6  0x00002ae9441a3ef1 in dlopen () from /lib/libdl.so.2
> > > > #7  0x000000000040378b in analyze (comp=<value optimized out>,
> > > > include=0 '\0') at gbi.c:377
> > > > #8  0x0000000000403e1f in main (argc=4, argv=<value optimized out>)
> at
> > > > gbi.c
> > > >
> > > > :655
> > >
> > > Some crash inside dlopen? Weird...
> > >
> > > First you should compile without optimizations:
> > >
> > > $ make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g"
> > >
> > > Then to trace gbi3:
> > >
> > > $ gdb gbi3
> > > ...
> > > (gdb) run -p -r /home/jredrejo/64bits/debian/ gb.gtk
> > > ...
> >
> > No much difference:
> > (sid_amd64)jredrejo at ...569...:~/64bits$ gdb
> > /home/jredrejo/64bits/debian/bin/gbi3
> > GNU gdb 6.7.1-debian
> > Copyright (C) 2007 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html
> >
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu"...
> > Using host libthread_db library "/lib/libthread_db.so.1".
> > (gdb) run -p -r /home/jredrejo/64bits/debian/ gb.gtk
> > Starting program: /home/jredrejo/64bits/debian/bin/gbi3 -p -r
> > /home/jredrejo/64bits/debian/ gb.gtk
> > gb.gtk
> > [Thread debugging using libthread_db enabled]
> > Error while reading shared library symbols:
> > Cannot find new threads: generic error
> > Cannot find new threads: generic error
> > (gdb) bt
> > #0  0x00002add4832810e in ?? () from /lib64/ld-linux-x86-64.so.2
> > #1  0x00002add48323df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> > #2  0x00002add4832791b in ?? () from /lib64/ld-linux-x86-64.so.2
> > #3  0x00002add48534f8b in ?? () from /lib/libdl.so.2
> > #4  0x00002add48323df6 in ?? () from /lib64/ld-linux-x86-64.so.2
> > #5  0x00002add485354ed in ?? () from /lib/libdl.so.2
> > #6  0x00002add48534ef1 in dlopen () from /lib/libdl.so.2
> > #7  0x00000000004054b0 in analyze_native_component (path=0x609420
> > "/home/jredrejo/64bits/debian/lib/gambas3/gb.gtk.so")
> >     at gbi.c:377
> > #8  0x00000000004059d1 in analyze (comp=0x7fff62792bf8 "gb.gtk",
> include=0
> > '\0') at gbi.c:520
> > #9  0x0000000000405cde in main (argc=5, argv=0x7fff62791178) at gbi.c
> :678
> > (gdb)
>
> Do you know why there is no "segmentation fault" message? What is this
> "Error
> while reading shared library symbols" error? Is it a bug in gdb? Or
> apparently the shared library is corrupted, or unreadable by gdb.
>
> I have no idea about this problem at the moment... A crash inside dlopen()
> may
> be a bug in it. I will wait for the compilation of gb.qt to see if there
> is
> the same problem (The qt library is preloaded contratry the GTK+ library).
>
>
Ok, do you want me to try qt compilation as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080112/b48738fb/attachment.html>

From gambas at ...1...  Sat Jan 12 16:15:19 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sat, 12 Jan 2008 16:15:19 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801120711m1b592c17q2d1f888387a11194@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801121609.03943.gambas@...1...>
	<8eb28a500801120711m1b592c17q2d1f888387a11194@...178...>
Message-ID: <200801121615.19121.gambas@...1...>

On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
>
> Ok, do you want me to try qt compilation as well?

If you can, of course.

-- 
Benoit Minisini



From jredrejo at ...176...  Sat Jan 12 19:12:37 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Sat, 12 Jan 2008 19:12:37 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801121615.19121.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801121609.03943.gambas@...1...>
	<8eb28a500801120711m1b592c17q2d1f888387a11194@...178...>
	<200801121615.19121.gambas@...1...>
Message-ID: <8eb28a500801121012r3d500a07r804b0f440cfbd7df@...178...>

2008/1/12, Benoit Minisini <gambas at ...1...>:
>
> On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> >
> > Ok, do you want me to try qt compilation as well?
>
> If you can, of course.
>
> -


Compiling qt after revision 953 goes fine, but make install fails again with
gbi, with another component this time. There is also a strange ".info file
not found in component archive" when applying gbi to gb.qt:

....
make[3]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
make[4]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
make[4]: Nothing to be done for `install-exec-am'.
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.qt.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.qt.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.qt.la'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.la'
/usr/bin/install -c .libs/gb.qt.so.0.0.0
/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.so.0.0.0
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.so.0 && ln -s
gb.qt.so.0.0.0 gb.qt.so.0)
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.so && ln -s
gb.qt.so.0.0.0 gb.qt.so)
/usr/bin/install -c .libs/gb.qt.lai
/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.la
libtool: install: warning: remember to run `libtool --finish
/usr/lib/gambas3'
make  install-data-hook
make[5]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
Compiling the gb.qt project...
gb.qt
OK

Creating the information files for gb.qt component...
gb.qt
gbi3: warning: .info file not found in component archive.

make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
make[2]: Entering directory `/home/jredrejo/64bits/gb.qt'
make[3]: Entering directory `/home/jredrejo/64bits/gb.qt'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt'
make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt'
make[1]: Leaving directory `/home/jredrejo/64bits/gb.qt'
Making install in gb.qte
make[1]: Entering directory `/home/jredrejo/64bits/gb.qte'
make[2]: Entering directory `/home/jredrejo/64bits/gb.qte'
make[3]: Entering directory `/home/jredrejo/64bits/gb.qte'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/jredrejo/64bits/gb.qte'
make[2]: Leaving directory `/home/jredrejo/64bits/gb.qte'
make[1]: Leaving directory `/home/jredrejo/64bits/gb.qte'
Making install in gb.qt.kde
make[1]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
Making install in src
make[2]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
Making install in html
make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
make[4]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
make[4]: Nothing to be done for `install-exec-am'.
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.qt.kde.html.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.qt.kde.html.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /bin/sh ../../libtool --mode=install /usr/bin/install -c  '
gb.qt.kde.html.la'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.la'
/usr/bin/install -c .libs/gb.qt.kde.html.so.0.0.0
/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.so.0.0.0
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f
gb.qt.kde.html.so.0&& ln -s
gb.qt.kde.html.so.0.0.0 gb.qt.kde.html.so.0)
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.html.so &&
ln -s gb.qt.kde.html.so.0.0.0 gb.qt.kde.html.so)
/usr/bin/install -c .libs/gb.qt.kde.html.lai
/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.la
libtool: install: warning: remember to run `libtool --finish
/usr/lib/gambas3'
make  install-data-hook
make[5]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'

Creating the information files for gb.qt.kde.html component...
gb.qt.kde.html

make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
make[4]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
make[4]: Nothing to be done for `install-exec-am'.
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.qt.kde.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.qt.kde.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.qt.kde.la'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.la'
/usr/bin/install -c .libs/gb.qt.kde.so.0.0.0
/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.so.0.0.0
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.so.0 && ln
-s gb.qt.kde.so.0.0.0 gb.qt.kde.so.0)
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.so && ln -s
gb.qt.kde.so.0.0.0 gb.qt.kde.so)
/usr/bin/install -c .libs/gb.qt.kde.lai
/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.la
libtool: install: warning: remember to run `libtool --finish
/usr/lib/gambas3'
make  install-data-hook
make[5]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'

Creating the information files for gb.qt.kde component...
gb.qt.kde

make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
make[2]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
make[1]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
Making install in gb.sdl
make[1]: Entering directory `/home/jredrejo/64bits/gb.sdl'
make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl'
make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
make[1]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
Making install in gb.sdl.sound
make[1]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
Making install in src
make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'
make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'
make[3]: Nothing to be done for `install-exec-am'.
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.sdl.sound.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.sdl.sound.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.sdl.sound.la'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.la'
/usr/bin/install -c .libs/gb.sdl.sound.so.0.0.0
/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.so.0.0.0
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.sdl.sound.so.0 &&
ln -s gb.sdl.sound.so.0.0.0 gb.sdl.sound.so.0)
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.sdl.sound.so && ln
-s gb.sdl.sound.so.0.0.0 gb.sdl.sound.so)
/usr/bin/install -c .libs/gb.sdl.sound.lai
/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.la
libtool: install: warning: remember to run `libtool --finish
/usr/lib/gambas3'
make  install-data-hook
make[4]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'

Creating the information files for gb.sdl.sound component...
gb.sdl.sound

make[4]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
make[1]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
Making install in gb.xml
make[1]: Entering directory `/home/jredrejo/64bits/gb.xml'
Making install in src
make[2]: Entering directory `/home/jredrejo/64bits/gb.xml/src'
Making install in xslt
make[3]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'
make[4]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'
make[4]: Nothing to be done for `install-exec-am'.
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.xml.xslt.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.xml.xslt.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /bin/sh ../../libtool --mode=install /usr/bin/install -c  'gb.xml.xslt.la'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.la'
/usr/bin/install -c .libs/gb.xml.xslt.so.0.0.0
/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.so.0.0.0
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.xml.xslt.so.0 &&
ln -s gb.xml.xslt.so.0.0.0 gb.xml.xslt.so.0)
(cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.xml.xslt.so && ln
-s gb.xml.xslt.so.0.0.0 gb.xml.xslt.so)
/usr/bin/install -c .libs/gb.xml.xslt.lai
/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.la
libtool: install: warning: remember to run `libtool --finish
/usr/lib/gambas3'
make  install-data-hook
make[5]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'

Creating the information files for gb.xml.xslt component...
gb.xml.xslt

make[5]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
make[4]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
make[3]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
Making install in rpc
make[3]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
make[4]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
make[4]: Nothing to be done for `install-exec-am'.
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.xml.rpc.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.rpc.component'
test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
"/home/jredrejo/64bits/debian//lib/gambas3"
 /usr/bin/install -c -m 644 'gb.xml.rpc.component'
'/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.rpc.component'
make  install-data-hook
make[5]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
Compiling the gb.xml.rpc project...
gb.xml.rpc
gbi3: warning: component gb.xml.rpc not found
/home/jredrejo/64bits/gb.xml/src/rpc/gb.xml.rpc/RpcClient.class:110: Unknown
identifier: XmlReader

Creating the information files for gb.xml.rpc component...
gb.xml.rpc
make[5]: *** [install-data-hook] Segmentation fault
make[5]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
make[4]: *** [install-data-am] Error 2
make[4]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/jredrejo/64bits/gb.xml/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/jredrejo/64bits/gb.xml'
make: *** [install-recursive] Error 1




(etch_amd64)jredrejo at ...569...:~/64bits$ ls gb.xml/src/rpc/
gb.xml.rpc  gb.xml.rpc.component  Makefile  Makefile.am  Makefile.in
(etch_amd64)jredrejo at ...569...:~/64bits$ ls gb.xml/src/rpc/gb.xml.rpc
gb.xml.rpc.gambas  miniServer.class  RpcArray.class  RpcClient.class
RpcServer.class  RpcType.class  XmlRpc.class
hPost.class        Module1.module    RpcAtom.class   RpcFunction.class
RpcStruct.class  Tools.module
(etch_amd64)jredrejo at ...569...:~/64bits$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080112/3c98360e/attachment.html>

From gambas at ...1...  Sat Jan 12 20:44:35 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sat, 12 Jan 2008 20:44:35 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801121012r3d500a07r804b0f440cfbd7df@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801121615.19121.gambas@...1...>
	<8eb28a500801121012r3d500a07r804b0f440cfbd7df@...178...>
Message-ID: <200801122044.35247.gambas@...1...>

On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
>
> Compiling qt after revision 953 goes fine, but make install fails again
> with gbi, with another component this time. There is also a strange ".info
> file not found in component archive" when applying gbi to gb.qt:
>
> ....
> make[3]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
> make[4]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
> make[4]: Nothing to be done for `install-exec-am'.
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.qt.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.qt.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.qt.la'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.la'
> /usr/bin/install -c .libs/gb.qt.so.0.0.0
> /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.so.0.0.0
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.so.0 && ln -s
> gb.qt.so.0.0.0 gb.qt.so.0)
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.so && ln -s
> gb.qt.so.0.0.0 gb.qt.so)
> /usr/bin/install -c .libs/gb.qt.lai
> /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.la
> libtool: install: warning: remember to run `libtool --finish
> /usr/lib/gambas3'
> make  install-data-hook
> make[5]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
> Compiling the gb.qt project...
> gb.qt
> OK
>
> Creating the information files for gb.qt component...
> gb.qt
> gbi3: warning: .info file not found in component archive.

gbi3 couldn't find the .info file in the gb.qt.gambas archive. This means 
there is a bug somewhere between the compiler, the archiver and the informer.

You can check that by compiling the gb.qt project by hand:
$ cd /home/jredrejo/64bits/gb.qt/src/gb.qt
$ gbc3 -agtv
...
$ ls -la .info .list
$ gba3 -v
...

With the output, you should see if the .info file is included in the archive.

>
> make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
> make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
> make[2]: Entering directory `/home/jredrejo/64bits/gb.qt'
> make[3]: Entering directory `/home/jredrejo/64bits/gb.qt'
> make[3]: Nothing to be done for `install-exec-am'.
> make[3]: Nothing to be done for `install-data-am'.
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt'
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt'
> make[1]: Leaving directory `/home/jredrejo/64bits/gb.qt'
> Making install in gb.qte
> make[1]: Entering directory `/home/jredrejo/64bits/gb.qte'
> make[2]: Entering directory `/home/jredrejo/64bits/gb.qte'
> make[3]: Entering directory `/home/jredrejo/64bits/gb.qte'
> make[3]: Nothing to be done for `install-exec-am'.
> make[3]: Nothing to be done for `install-data-am'.
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.qte'
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.qte'
> make[1]: Leaving directory `/home/jredrejo/64bits/gb.qte'
> Making install in gb.qt.kde
> make[1]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
> Making install in src
> make[2]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
> Making install in html
> make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> make[4]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> make[4]: Nothing to be done for `install-exec-am'.
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.qt.kde.html.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.qt.kde.html.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /bin/sh ../../libtool --mode=install /usr/bin/install -c  '
> gb.qt.kde.html.la'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.la'
> /usr/bin/install -c .libs/gb.qt.kde.html.so.0.0.0
> /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.so.0.0.0
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f
> gb.qt.kde.html.so.0&& ln -s
> gb.qt.kde.html.so.0.0.0 gb.qt.kde.html.so.0)
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.html.so &&
> ln -s gb.qt.kde.html.so.0.0.0 gb.qt.kde.html.so)
> /usr/bin/install -c .libs/gb.qt.kde.html.lai
> /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.la
> libtool: install: warning: remember to run `libtool --finish
> /usr/lib/gambas3'
> make  install-data-hook
> make[5]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
>
> Creating the information files for gb.qt.kde.html component...
> gb.qt.kde.html
>
> make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
> make[4]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
> make[4]: Nothing to be done for `install-exec-am'.
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.qt.kde.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.qt.kde.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.qt.kde.la'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.la'
> /usr/bin/install -c .libs/gb.qt.kde.so.0.0.0
> /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.so.0.0.0
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.so.0 && ln
> -s gb.qt.kde.so.0.0.0 gb.qt.kde.so.0)
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.so && ln
> -s gb.qt.kde.so.0.0.0 gb.qt.kde.so)
> /usr/bin/install -c .libs/gb.qt.kde.lai
> /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.la
> libtool: install: warning: remember to run `libtool --finish
> /usr/lib/gambas3'
> make  install-data-hook
> make[5]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
>
> Creating the information files for gb.qt.kde component...
> gb.qt.kde
>
> make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
> make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
> make[2]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
> make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
> make[3]: Nothing to be done for `install-exec-am'.
> make[3]: Nothing to be done for `install-data-am'.
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
> make[1]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
> Making install in gb.sdl
> make[1]: Entering directory `/home/jredrejo/64bits/gb.sdl'
> make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl'
> make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl'
> make[3]: Nothing to be done for `install-exec-am'.
> make[3]: Nothing to be done for `install-data-am'.
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
> make[1]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
> Making install in gb.sdl.sound
> make[1]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
> Making install in src
> make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> make[3]: Nothing to be done for `install-exec-am'.
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.sdl.sound.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.sdl.sound.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.sdl.sound.la'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.la'
> /usr/bin/install -c .libs/gb.sdl.sound.so.0.0.0
> /home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.so.0.0.0
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.sdl.sound.so.0 &&
> ln -s gb.sdl.sound.so.0.0.0 gb.sdl.sound.so.0)
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.sdl.sound.so &&
> ln -s gb.sdl.sound.so.0.0.0 gb.sdl.sound.so)
> /usr/bin/install -c .libs/gb.sdl.sound.lai
> /home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.la
> libtool: install: warning: remember to run `libtool --finish
> /usr/lib/gambas3'
> make  install-data-hook
> make[4]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'
>
> Creating the information files for gb.sdl.sound component...
> gb.sdl.sound
>
> make[4]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
> make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
> make[3]: Nothing to be done for `install-exec-am'.
> make[3]: Nothing to be done for `install-data-am'.
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
> make[1]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
> Making install in gb.xml
> make[1]: Entering directory `/home/jredrejo/64bits/gb.xml'
> Making install in src
> make[2]: Entering directory `/home/jredrejo/64bits/gb.xml/src'
> Making install in xslt
> make[3]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> make[4]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> make[4]: Nothing to be done for `install-exec-am'.
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.xml.xslt.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.xml.xslt.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /bin/sh ../../libtool --mode=install /usr/bin/install -c  'gb.xml.xslt.la'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.la'
> /usr/bin/install -c .libs/gb.xml.xslt.so.0.0.0
> /home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.so.0.0.0
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.xml.xslt.so.0 &&
> ln -s gb.xml.xslt.so.0.0.0 gb.xml.xslt.so.0)
> (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.xml.xslt.so && ln
> -s gb.xml.xslt.so.0.0.0 gb.xml.xslt.so)
> /usr/bin/install -c .libs/gb.xml.xslt.lai
> /home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.la
> libtool: install: warning: remember to run `libtool --finish
> /usr/lib/gambas3'
> make  install-data-hook
> make[5]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'
>
> Creating the information files for gb.xml.xslt component...
> gb.xml.xslt
>
> make[5]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> make[4]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> Making install in rpc
> make[3]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> make[4]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> make[4]: Nothing to be done for `install-exec-am'.
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.xml.rpc.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.rpc.component'
> test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> "/home/jredrejo/64bits/debian//lib/gambas3"
>  /usr/bin/install -c -m 644 'gb.xml.rpc.component'
> '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.rpc.component'
> make  install-data-hook
> make[5]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> Compiling the gb.xml.rpc project...
> gb.xml.rpc
> gbi3: warning: component gb.xml.rpc not found
> /home/jredrejo/64bits/gb.xml/src/rpc/gb.xml.rpc/RpcClient.class:110:
> Unknown identifier: XmlReader
>
> Creating the information files for gb.xml.rpc component...
> gb.xml.rpc
> make[5]: *** [install-data-hook] Segmentation fault
> make[5]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> make[4]: *** [install-data-am] Error 2
> make[4]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> make[3]: *** [install-am] Error 2
> make[3]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> make[2]: *** [install-recursive] Error 1
> make[2]: Leaving directory `/home/jredrejo/64bits/gb.xml/src'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/home/jredrejo/64bits/gb.xml'
> make: *** [install-recursive] Error 1
>

Interesting, as gb.xml.rpc is only a Gambas component. Can you get the 
backtrace with gdb?

-- 
Benoit Minisini



From scatman at ...571...  Sun Jan 13 13:07:09 2008
From: scatman at ...571... (scatman)
Date: Sun, 13 Jan 2008 13:07:09 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
Message-ID: <200801131307.09646.scatman@...571...>

Hello,

i have successfully compiled Gambas 64bit on Gentoo.
SVN Revision 954

gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)
glibc 2.7-r1

But if i try to execute a Program, Gambas Segfault.

main/gbx/gbx3 ./examples/examples/Basic/Blights/
Warning: The 64 bits version of Gambas is not stable yet.
Segmentation fault

main/gbx/gbx3 -d ./examples/examples/Basic/Blights/
gbx3: too many project files.

######## gdb ########
(gdb) r ./examples/examples/Basic/Blights/
Starting 
program: /home/test/64bits/main/gbx/gbx3 ./examples/examples/Basic/Blights/
warning: no loadable sections found in added symbol-file system-supplied DSO 
at 0x7fff023fd000
Warning: The 64 bits version of Gambas is not stable yet.

Program received signal SIGSEGV, Segmentation fault.
LIST_remove (p_first=0x63e3a0, node=0x648cf0, list=<value optimized out>)
    at ../share/gb_list_temp.h:78
78          if (node == last)


(gdb) bt
#0  LIST_remove (p_first=0x63e3a0, node=0x648cf0, list=<value optimized 
out>)
    at ../share/gb_list_temp.h:78
#1  0x0000000000422b89 in COMPONENT_delete (comp=0x648cf0) at 
gbx_component.c:215
#2  0x0000000000422db8 in COMPONENT_create (name=0x648f7e "gb.gtk") at 
gbx_component.c:199
#3  0x0000000000410371 in project_library (name=<value optimized out>, 
len=<value optimized out>)
    at gbx_project.c:108
#4  0x000000000041050d in PROJECT_load () at gbx_project.c:174
#5  0x000000000041b1bd in init 
(file=0x7fff0223aeab "./examples/examples/Basic/Blights/")
    at gbx.c:85
#6  0x000000000041b57a in main (argc=1, argv=0x7fff02238cd8) at gbx.c:292


(gdb) l
73        }
74        else
75        {
76          last = TO_LIST(*first)->prev;
77
78          if (node == last)
79            TO_LIST(*first)->prev = prev;
80
81          if (prev)
82            TO_LIST(prev)->next = next;

Thanks



From gambas at ...1...  Sun Jan 13 18:56:44 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 13 Jan 2008 18:56:44 +0100
Subject: [Gambas-devel] Translation for spanish
In-Reply-To: <475475.62857.qm@...566...>
References: <475475.62857.qm@...566...>
Message-ID: <200801131856.45006.gambas@...1...>

On jeudi 10 janvier 2008, David Villalobos Cambronero wrote:
> Hi all,
>
> For Gambas 2.0 I found some new strings... so here is the translation
> file... hope someone can upload it
>
> Best regards
>
> David
>

Thanks, I merged the file.

-- 
Benoit Minisini



From gambas at ...1...  Sun Jan 13 18:57:50 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 13 Jan 2008 18:57:50 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
In-Reply-To: <200801131307.09646.scatman@...571...>
References: <200801131307.09646.scatman@...571...>
Message-ID: <200801131857.51048.gambas@...1...>

On dimanche 13 janvier 2008, scatman wrote:
> Hello,
>
> i have successfully compiled Gambas 64bit on Gentoo.
> SVN Revision 954
>
> gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)
> glibc 2.7-r1
>
> But if i try to execute a Program, Gambas Segfault.
>
> main/gbx/gbx3 ./examples/examples/Basic/Blights/
> Warning: The 64 bits version of Gambas is not stable yet.
> Segmentation fault
>
> main/gbx/gbx3 -d ./examples/examples/Basic/Blights/
> gbx3: too many project files.
>
> ######## gdb ########
> (gdb) r ./examples/examples/Basic/Blights/
> Starting
> program: /home/test/64bits/main/gbx/gbx3 ./examples/examples/Basic/Blights/
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7fff023fd000
> Warning: The 64 bits version of Gambas is not stable yet.
>
> Program received signal SIGSEGV, Segmentation fault.
> LIST_remove (p_first=0x63e3a0, node=0x648cf0, list=<value optimized out>)
>     at ../share/gb_list_temp.h:78
> 78          if (node == last)
>
>
> (gdb) bt
> #0  LIST_remove (p_first=0x63e3a0, node=0x648cf0, list=<value optimized
> out>)
>     at ../share/gb_list_temp.h:78
> #1  0x0000000000422b89 in COMPONENT_delete (comp=0x648cf0) at
> gbx_component.c:215
> #2  0x0000000000422db8 in COMPONENT_create (name=0x648f7e "gb.gtk") at
> gbx_component.c:199
> #3  0x0000000000410371 in project_library (name=<value optimized out>,
> len=<value optimized out>)
>     at gbx_project.c:108
> #4  0x000000000041050d in PROJECT_load () at gbx_project.c:174
> #5  0x000000000041b1bd in init
> (file=0x7fff0223aeab "./examples/examples/Basic/Blights/")
>     at gbx.c:85
> #6  0x000000000041b57a in main (argc=1, argv=0x7fff02238cd8) at gbx.c:292
>
>
> (gdb) l
> 73        }
> 74        else
> 75        {
> 76          last = TO_LIST(*first)->prev;
> 77
> 78          if (node == last)
> 79            TO_LIST(*first)->prev = prev;
> 80
> 81          if (prev)
> 82            TO_LIST(prev)->next = next;
>
> Thanks
>

Does it segfaults at the same place if you run another example?

-- 
Benoit Minisini



From ron at ...572...  Sun Jan 13 19:15:00 2008
From: ron at ...572... (Ron)
Date: Sun, 13 Jan 2008 19:15:00 +0100
Subject: [Gambas-devel] 64bit autoconf requirement
Message-ID: <478A5524.5060402@...572...>

Hi Benoit,

The 64bits gambas  trunk uses a different autoconf as the 32bits version 
does.
It needs 2.61 to support the no-recursive flag, CentOS 5.1 and RedHat 
RHEL5 still have 2.59-12, this means gambas cannot be compiled on those 
platforms
without installing an unsupported package.

Otherwise you get this error while running ./reconf
/usr/bin/autoreconf: unrecognized option `--no-recursive'

I have:
[root at ...573... 64bits]# yum list installed|grep autoconf
autoconf.noarch                          2.59-12                
installed     

I then compiled and installed autoconf 2.61 manually to be able to 
provide you with debug info for gambas 64 bits.
Would be nice if the final release uses the old autoconf again to 
prevent compilation problems (if possible)

My ./configure run keeps failing with:
------- cut ---------
...
...
=== configuring in gb.sdl (/home/ron/build/gambas/64bits/gb.sdl)
configure: running /bin/sh ./configure '--prefix=/usr/local'  
--cache-file=/dev/null --srcdir=.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-unknown-linux-gnu
checking for style of include used by make... GNU
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking dependency style of g++... none
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for setenv... yes
checking for unsetenv... yes
checking for getdomainname... yes
checking for getpt... yes
checking for ccache... no
checking for main in -lm... yes
checking for main in -lz... yes
checking for main in -lgcc_s... yes
checking for main in -lstdc++... no
checking target system... LINUX
checking which extension is used for shared libraries... .so
checking for threading compiler options... -D_REENTRANT
checking for threading linker options... -lpthread
checking for mathematic libraries... -lm
checking CFLAGS for gcc -fvisibility=hidden... -fvisibility=hidden
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking how to recognize dependent libraries... pass_all
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 98304
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports 
shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen... no
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
appending configuration tag "F77" to libtool
checking for X... libraries /usr/lib64, headers
checking whether -R must be followed by a space... neither works
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
./configure: line 21896: syntax error near unexpected token `1.2.8,'
./configure: line 21896: `GB_PATH_SDL(1.2.8, , touch DISABLED)'
configure: error: ./configure failed for gb.sdl
---------- cut -------------

Any idea? Or local problem...

I'm running CentOS 5.1 x86_64
Q6600 Core2Duo Quad
gcc 4.1.2
Gambas 64bits rev 954

Regards,
Ron.




From scatman at ...571...  Sun Jan 13 19:27:57 2008
From: scatman at ...571... (scatman)
Date: Sun, 13 Jan 2008 19:27:57 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
In-Reply-To: <200801131857.51048.gambas@...1...>
References: <200801131307.09646.scatman@...571...>
	<200801131857.51048.gambas@...1...>
	(sfid-20080113_185825_053681_1D251CB41A41D1D6)
Message-ID: <200801131927.57618.scatman@...571...>

Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:
> On dimanche 13 janvier 2008, scatman wrote:

>
> Does it segfaults at the same place if you run another example?

Yes, it segfaults allways with the same error.




From gambas at ...1...  Sun Jan 13 19:31:36 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 13 Jan 2008 19:31:36 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
In-Reply-To: <200801131927.57618.scatman@...571...>
References: <200801131307.09646.scatman@...571...>
	<200801131857.51048.gambas@...1...>
	<200801131927.57618.scatman@...571...>
Message-ID: <200801131931.36303.gambas@...1...>

On dimanche 13 janvier 2008, scatman wrote:
> Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:
> > On dimanche 13 janvier 2008, scatman wrote:
> >
> >
> > Does it segfaults at the same place if you run another example?
>
> Yes, it segfaults allways with the same error.
>
>

Can you recompile Gambas without optimizations, and send me the backtrace? 
Maybe I will have more information on the error...

$ make clean
$ make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g"

Thanks in advance.

Regards,

-- 
Benoit Minisini



From scatman at ...571...  Sun Jan 13 19:46:51 2008
From: scatman at ...571... (scatman)
Date: Sun, 13 Jan 2008 19:46:51 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
In-Reply-To: <200801131931.36303.gambas@...1...>
References: <200801131307.09646.scatman@...571...>
	<200801131927.57618.scatman@...571...>
	<200801131931.36303.gambas@...1...>
	(sfid-20080113_193433_256650_296BB88B4D2441F1)
Message-ID: <200801131946.51057.scatman@...571...>

Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:
> On dimanche 13 janvier 2008, scatman wrote:
> > Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:
> > > On dimanche 13 janvier 2008, scatman wrote:
> > >
> > >
> > > Does it segfaults at the same place if you run another example?
> >
> > Yes, it segfaults allways with the same error.
>
> Can you recompile Gambas without optimizations, and send me the
> backtrace? Maybe I will have more information on the error...


OK, here the backtrace.


gdb) r examples/examples/Basic/Blights/
Starting program: /home/test/64bits/main/gbx/gbx3 
examples/examples/Basic/Blights/
warning: no loadable sections found in added symbol-file system-supplied DSO 
at 0x7fff2effd000
Warning: The 64 bits version of Gambas is not stable yet.

Program received signal SIGSEGV, Segmentation fault.
0x000000000040671d in LIST_remove (p_first=0x657fb0, node=0x662cf0, 
list=0x662cfc)
    at ../share/gb_list_temp.h:76
76          last = TO_LIST(*first)->prev;



(gdb) bt
#0  0x000000000040671d in LIST_remove (p_first=0x657fb0, node=0x662cf0, 
list=0x662cfc)
    at ../share/gb_list_temp.h:76
#1  0x00000000004391a7 in COMPONENT_delete (comp=0x662cf0) at 
gbx_component.c:215
#2  0x000000000043912c in COMPONENT_create (name=0x662f7e "gb.gtk") at 
gbx_component.c:199
#3  0x00000000004195db in project_library (name=0x662f7e "gb.gtk", len=6) at 
gbx_project.c:108
#4  0x0000000000419740 in project_command (line=0x662f76 "Library=gb.gtk", 
len=14) at gbx_project.c:174
#5  0x0000000000419891 in project_analyze (addr=0x662f30 "# Gambas Project 
File 2.0\nStartup=win1",
    len=295) at gbx_project.c:223
#6  0x0000000000419c1e in PROJECT_load () at gbx_project.c:357
#7  0x000000000042b98e in init 
(file=0x7fff2efaaec8 "examples/examples/Basic/Blights/") at gbx.c:85
#8  0x000000000042bf0c in main (argc=1, argv=0x7fff2efa9a68) at gbx.c:292

thanks



From gambas at ...1...  Sun Jan 13 19:57:30 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 13 Jan 2008 19:57:30 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
In-Reply-To: <200801131946.51057.scatman@...571...>
References: <200801131307.09646.scatman@...571...>
	<200801131931.36303.gambas@...1...>
	<200801131946.51057.scatman@...571...>
Message-ID: <200801131957.30927.gambas@...1...>

On dimanche 13 janvier 2008, scatman wrote:
> Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:
> > On dimanche 13 janvier 2008, scatman wrote:
> > > Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:
> > > > On dimanche 13 janvier 2008, scatman wrote:
> > > >
> > > >
> > > > Does it segfaults at the same place if you run another example?
> > >
> > > Yes, it segfaults allways with the same error.
> >
> > Can you recompile Gambas without optimizations, and send me the
> > backtrace? Maybe I will have more information on the error...
>
> OK, here the backtrace.
>
>
> gdb) r examples/examples/Basic/Blights/
> Starting program: /home/test/64bits/main/gbx/gbx3
> examples/examples/Basic/Blights/
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7fff2effd000
> Warning: The 64 bits version of Gambas is not stable yet.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000040671d in LIST_remove (p_first=0x657fb0, node=0x662cf0,
> list=0x662cfc)
>     at ../share/gb_list_temp.h:76
> 76          last = TO_LIST(*first)->prev;
>
>
>
> (gdb) bt
> #0  0x000000000040671d in LIST_remove (p_first=0x657fb0, node=0x662cf0,
> list=0x662cfc)
>     at ../share/gb_list_temp.h:76
> #1  0x00000000004391a7 in COMPONENT_delete (comp=0x662cf0) at
> gbx_component.c:215
> #2  0x000000000043912c in COMPONENT_create (name=0x662f7e "gb.gtk") at
> gbx_component.c:199
> #3  0x00000000004195db in project_library (name=0x662f7e "gb.gtk", len=6)
> at gbx_project.c:108
> #4  0x0000000000419740 in project_command (line=0x662f76 "Library=gb.gtk",
> len=14) at gbx_project.c:174
> #5  0x0000000000419891 in project_analyze (addr=0x662f30 "# Gambas Project
> File 2.0\nStartup=win1",
>     len=295) at gbx_project.c:223
> #6  0x0000000000419c1e in PROJECT_load () at gbx_project.c:357
> #7  0x000000000042b98e in init
> (file=0x7fff2efaaec8 "examples/examples/Basic/Blights/") at gbx.c:85
> #8  0x000000000042bf0c in main (argc=1, argv=0x7fff2efa9a68) at gbx.c:292
>
> thanks
>

Arf. This bug is not 64 bits related. It is raised when a library specified in 
the .project file cannot be loaded. In your case, gb.gtk. Did you compile 
gb.gtk?

-- 
Benoit Minisini



From scatman at ...571...  Sun Jan 13 20:13:23 2008
From: scatman at ...571... (scatman)
Date: Sun, 13 Jan 2008 20:13:23 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
In-Reply-To: <200801131957.30927.gambas@...1...>
References: <200801131307.09646.scatman@...571...>
	<200801131946.51057.scatman@...571...>
	<200801131957.30927.gambas@...1...>
	(sfid-20080113_195938_618247_81C67540F83BAEFF)
Message-ID: <200801132013.23179.scatman@...571...>

Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:

> Arf. This bug is not 64 bits related. It is raised when a library
> specified in the .project file cannot be loaded. In your case, gb.gtk.
> Did you compile gb.gtk?

Yes, here the configure output.

./configure

THESE COMPONENTS ARE DISABLED:

- gb.corba
- gb.db.firebird
- gb.db.mysql
- gb.db.odbc
- gb.db.postgresql
- gb.db.sqlite2
- gb.qte

export "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g"

make 

gbx3 out from gdb

(gdb) r examples/examples/Basic/Blights/
Starting program: /home/test/64bits/main/gbx/gbx3 
examples/examples/Basic/Blights/
warning: no loadable sections found in added symbol-file system-supplied DSO 
at 0x7fff823fd000
Warning: The 64 bits version of Gambas is not stable yet.

Program received signal SIGSEGV, Segmentation fault.
0x000000000040671d in LIST_remove (p_first=0x657fb0, node=0x662cf0,
    list=0x662cfc) at ../share/gb_list_temp.h:76
76          last = TO_LIST(*first)->prev;
(gdb) bt
#0  0x000000000040671d in LIST_remove (p_first=0x657fb0, node=0x662cf0,
    list=0x662cfc) at ../share/gb_list_temp.h:76
#1  0x00000000004391a7 in COMPONENT_delete (comp=0x662cf0)
    at gbx_component.c:215
#2  0x000000000043912c in COMPONENT_create (name=0x662f7e "gb.gtk")
    at gbx_component.c:199
#3  0x00000000004195db in project_library (name=0x662f7e "gb.gtk", len=6)
    at gbx_project.c:108
#4  0x0000000000419740 in project_command (line=0x662f76 "Library=gb.gtk",
    len=14) at gbx_project.c:174
#5  0x0000000000419891 in project_analyze (
    addr=0x662f30 "# Gambas Project File 2.0\nStartup=win1", len=295)
    at gbx_project.c:223
#6  0x0000000000419c1e in PROJECT_load () at gbx_project.c:357



From gambas at ...1...  Sun Jan 13 20:21:16 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 13 Jan 2008 20:21:16 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
In-Reply-To: <200801132013.23179.scatman@...571...>
References: <200801131307.09646.scatman@...571...>
	<200801131957.30927.gambas@...1...>
	<200801132013.23179.scatman@...571...>
Message-ID: <200801132021.16655.gambas@...1...>

On dimanche 13 janvier 2008, scatman wrote:
> Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:
> > Arf. This bug is not 64 bits related. It is raised when a library
> > specified in the .project file cannot be loaded. In your case, gb.gtk.
> > Did you compile gb.gtk?
>
> Yes, here the configure output.
>
> ./configure
>
> THESE COMPONENTS ARE DISABLED:
>
> - gb.corba
> - gb.db.firebird
> - gb.db.mysql
> - gb.db.odbc
> - gb.db.postgresql
> - gb.db.sqlite2
> - gb.qte
>
> export "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g"
>
> make
>
> gbx3 out from gdb
>
> (gdb) r examples/examples/Basic/Blights/
> Starting program: /home/test/64bits/main/gbx/gbx3
> examples/examples/Basic/Blights/
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7fff823fd000
> Warning: The 64 bits version of Gambas is not stable yet.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000040671d in LIST_remove (p_first=0x657fb0, node=0x662cf0,
>     list=0x662cfc) at ../share/gb_list_temp.h:76
> 76          last = TO_LIST(*first)->prev;
> (gdb) bt
> #0  0x000000000040671d in LIST_remove (p_first=0x657fb0, node=0x662cf0,
>     list=0x662cfc) at ../share/gb_list_temp.h:76
> #1  0x00000000004391a7 in COMPONENT_delete (comp=0x662cf0)
>     at gbx_component.c:215
> #2  0x000000000043912c in COMPONENT_create (name=0x662f7e "gb.gtk")
>     at gbx_component.c:199
> #3  0x00000000004195db in project_library (name=0x662f7e "gb.gtk", len=6)
>     at gbx_project.c:108
> #4  0x0000000000419740 in project_command (line=0x662f76 "Library=gb.gtk",
>     len=14) at gbx_project.c:174
> #5  0x0000000000419891 in project_analyze (
>     addr=0x662f30 "# Gambas Project File 2.0\nStartup=win1", len=295)
>     at gbx_project.c:223
> #6  0x0000000000419c1e in PROJECT_load () at gbx_project.c:357
>

This bug has been fixed in the revision 958.

Regards,

-- 
Benoit Minisini



From scatman at ...571...  Sun Jan 13 22:52:20 2008
From: scatman at ...571... (scatman)
Date: Sun, 13 Jan 2008 22:52:20 +0100
Subject: [Gambas-devel] gbx3 SIGSEGV
In-Reply-To: <200801132021.16655.gambas@...1...>
References: <200801131307.09646.scatman@...571...>
	<200801132013.23179.scatman@...571...>
	<200801132021.16655.gambas@...1...>
	(sfid-20080113_202217_189832_D0682435588C549F)
Message-ID: <200801132252.20785.scatman@...571...>

Am Sonntag, 13. Januar 2008 schrieb Benoit Minisini:


> This bug has been fixed in the revision 958.

Revision 960

(gdb) r /home/test/64bits/examples/examples/Basic/Blights/
Starting 
program: /usr/local/bin/gbx3 /home/forty/test/64bits/examples/examples/Basic/Blights/
warning: no loadable sections found in added symbol-file system-supplied DSO 
at 0x7fffeeffd000
Warning: The 64 bits version of Gambas is not stable yet.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()


(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00002abcbcdb7063 in GB_INIT () at main.cpp:221
#2  0x00000000004108f1 in LIBRARY_load (lib=0x648d40) at gbx_library.c:478
#3  0x0000000000422a89 in COMPONENT_load (comp=0x648ce0)
    at gbx_component.c:250
#4  0x0000000000422d6b in COMPONENT_load_all () at gbx_component.c:110
#5  0x00000000004104c4 in PROJECT_load () at gbx_project.c:362
#6  0x000000000041b101 in init (    
file=0x7fffeef78eab "/home/test/64bits/examples/examples/Basic/Blights/") 
at gbx.c:85
#7  0x000000000041b4be in main (argc=1, argv=0x7fffeef77a38) at gbx.c:292


(gdb) l
113       EVENT_exit();
114       FILE_exit();
115       STRING_exit();
116             ERROR_clear();
117       STACK_exit();
118     }
119
120
121     int main(int argc, char **argv)
122     {
(gdb)          

thanks



From jredrejo at ...176...  Mon Jan 14 13:58:16 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Mon, 14 Jan 2008 13:58:16 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <200801122044.35247.gambas@...1...>
References: <200801091614.44194.gambas@...1...>
	<200801121615.19121.gambas@...1...>
	<8eb28a500801121012r3d500a07r804b0f440cfbd7df@...178...>
	<200801122044.35247.gambas@...1...>
Message-ID: <8eb28a500801140458y332dccd4hed06452f3f87bff8@...178...>

After merging svn revision 970 all these problems have disappeared, gbi3
works fine now with gb.gtk and gb.xml. No more core dump of segment
violations. Compilation of the examples also worked (except in the examples
whose needed components weren't compiled, obviously).

Congrats.

Jos? L.

2008/1/12, Benoit Minisini <gambas at ...1...>:
>
> On samedi 12 janvier 2008, Jos? Luis Redrejo wrote:
> >
> > Compiling qt after revision 953 goes fine, but make install fails again
> > with gbi, with another component this time. There is also a strange
> ".info
> > file not found in component archive" when applying gbi to gb.qt:
> >
> > ....
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
> > make[4]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
> > make[4]: Nothing to be done for `install-exec-am'.
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.qt.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.qt.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.qt.la'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.la'
> > /usr/bin/install -c .libs/gb.qt.so.0.0.0
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.so.0.0.0
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.so.0 && ln
> -s
> > gb.qt.so.0.0.0 gb.qt.so.0)
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.so && ln -s
> > gb.qt.so.0.0.0 gb.qt.so)
> > /usr/bin/install -c .libs/gb.qt.lai
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.la
> > libtool: install: warning: remember to run `libtool --finish
> > /usr/lib/gambas3'
> > make  install-data-hook
> > make[5]: Entering directory `/home/jredrejo/64bits/gb.qt/src'
> > Compiling the gb.qt project...
> > gb.qt
> > OK
> >
> > Creating the information files for gb.qt component...
> > gb.qt
> > gbi3: warning: .info file not found in component archive.
>
> gbi3 couldn't find the .info file in the gb.qt.gambas archive. This means
> there is a bug somewhere between the compiler, the archiver and the
> informer.
>
> You can check that by compiling the gb.qt project by hand:
> $ cd /home/jredrejo/64bits/gb.qt/src/gb.qt
> $ gbc3 -agtv
> ...
> $ ls -la .info .list
> $ gba3 -v
> ...
>
> With the output, you should see if the .info file is included in the
> archive.
>
> >
> > make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
> > make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt/src'
> > make[2]: Entering directory `/home/jredrejo/64bits/gb.qt'
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.qt'
> > make[3]: Nothing to be done for `install-exec-am'.
> > make[3]: Nothing to be done for `install-data-am'.
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt'
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt'
> > make[1]: Leaving directory `/home/jredrejo/64bits/gb.qt'
> > Making install in gb.qte
> > make[1]: Entering directory `/home/jredrejo/64bits/gb.qte'
> > make[2]: Entering directory `/home/jredrejo/64bits/gb.qte'
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.qte'
> > make[3]: Nothing to be done for `install-exec-am'.
> > make[3]: Nothing to be done for `install-data-am'.
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.qte'
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.qte'
> > make[1]: Leaving directory `/home/jredrejo/64bits/gb.qte'
> > Making install in gb.qt.kde
> > make[1]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
> > Making install in src
> > make[2]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
> > Making install in html
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> > make[4]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> > make[4]: Nothing to be done for `install-exec-am'.
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.qt.kde.html.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.qt.kde.html.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /bin/sh ../../libtool --mode=install /usr/bin/install -c  '
> > gb.qt.kde.html.la'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.la'
> > /usr/bin/install -c .libs/gb.qt.kde.html.so.0.0.0
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.so.0.0.0
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f
> > gb.qt.kde.html.so.0&& ln -s
> > gb.qt.kde.html.so.0.0.0 gb.qt.kde.html.so.0)
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.html.so&&
> > ln -s gb.qt.kde.html.so.0.0.0 gb.qt.kde.html.so)
> > /usr/bin/install -c .libs/gb.qt.kde.html.lai
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.html.la
> > libtool: install: warning: remember to run `libtool --finish
> > /usr/lib/gambas3'
> > make  install-data-hook
> > make[5]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> >
> > Creating the information files for gb.qt.kde.html component...
> > gb.qt.kde.html
> >
> > make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> > make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src/html'
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
> > make[4]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
> > make[4]: Nothing to be done for `install-exec-am'.
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.qt.kde.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.qt.kde.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.qt.kde.la'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.la'
> > /usr/bin/install -c .libs/gb.qt.kde.so.0.0.0
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.so.0.0.0
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.so.0 &&
> ln
> > -s gb.qt.kde.so.0.0.0 gb.qt.kde.so.0)
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.qt.kde.so &&
> ln
> > -s gb.qt.kde.so.0.0.0 gb.qt.kde.so)
> > /usr/bin/install -c .libs/gb.qt.kde.lai
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.qt.kde.la
> > libtool: install: warning: remember to run `libtool --finish
> > /usr/lib/gambas3'
> > make  install-data-hook
> > make[5]: Entering directory `/home/jredrejo/64bits/gb.qt.kde/src'
> >
> > Creating the information files for gb.qt.kde component...
> > gb.qt.kde
> >
> > make[5]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
> > make[4]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde/src'
> > make[2]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.qt.kde'
> > make[3]: Nothing to be done for `install-exec-am'.
> > make[3]: Nothing to be done for `install-data-am'.
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
> > make[1]: Leaving directory `/home/jredrejo/64bits/gb.qt.kde'
> > Making install in gb.sdl
> > make[1]: Entering directory `/home/jredrejo/64bits/gb.sdl'
> > make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl'
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl'
> > make[3]: Nothing to be done for `install-exec-am'.
> > make[3]: Nothing to be done for `install-data-am'.
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
> > make[1]: Leaving directory `/home/jredrejo/64bits/gb.sdl'
> > Making install in gb.sdl.sound
> > make[1]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
> > Making install in src
> > make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> > make[3]: Nothing to be done for `install-exec-am'.
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.sdl.sound.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.sdl.sound.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /bin/sh ../libtool --mode=install /usr/bin/install -c  'gb.sdl.sound.la
> '
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.la'
> > /usr/bin/install -c .libs/gb.sdl.sound.so.0.0.0
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.so.0.0.0
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.sdl.sound.so.0&&
> > ln -s gb.sdl.sound.so.0.0.0 gb.sdl.sound.so.0)
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.sdl.sound.so&&
> > ln -s gb.sdl.sound.so.0.0.0 gb.sdl.sound.so)
> > /usr/bin/install -c .libs/gb.sdl.sound.lai
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.sdl.sound.la
> > libtool: install: warning: remember to run `libtool --finish
> > /usr/lib/gambas3'
> > make  install-data-hook
> > make[4]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> >
> > Creating the information files for gb.sdl.sound component...
> > gb.sdl.sound
> >
> > make[4]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound/src'
> > make[2]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.sdl.sound'
> > make[3]: Nothing to be done for `install-exec-am'.
> > make[3]: Nothing to be done for `install-data-am'.
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
> > make[1]: Leaving directory `/home/jredrejo/64bits/gb.sdl.sound'
> > Making install in gb.xml
> > make[1]: Entering directory `/home/jredrejo/64bits/gb.xml'
> > Making install in src
> > make[2]: Entering directory `/home/jredrejo/64bits/gb.xml/src'
> > Making install in xslt
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> > make[4]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> > make[4]: Nothing to be done for `install-exec-am'.
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.xml.xslt.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.xml.xslt.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /bin/sh ../../libtool --mode=install /usr/bin/install -c  '
> gb.xml.xslt.la'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.la'
> > /usr/bin/install -c .libs/gb.xml.xslt.so.0.0.0
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.so.0.0.0
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.xml.xslt.so.0&&
> > ln -s gb.xml.xslt.so.0.0.0 gb.xml.xslt.so.0)
> > (cd /home/jredrejo/64bits/debian//lib/gambas3 && rm -f gb.xml.xslt.so &&
> ln
> > -s gb.xml.xslt.so.0.0.0 gb.xml.xslt.so)
> > /usr/bin/install -c .libs/gb.xml.xslt.lai
> > /home/jredrejo/64bits/debian//lib/gambas3/gb.xml.xslt.la
> > libtool: install: warning: remember to run `libtool --finish
> > /usr/lib/gambas3'
> > make  install-data-hook
> > make[5]: Entering directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> >
> > Creating the information files for gb.xml.xslt component...
> > gb.xml.xslt
> >
> > make[5]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> > make[4]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/xslt'
> > Making install in rpc
> > make[3]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> > make[4]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> > make[4]: Nothing to be done for `install-exec-am'.
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.xml.rpc.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.rpc.component'
> > test -z "/home/jredrejo/64bits/debian//lib/gambas3" || mkdir -p --
> > "/home/jredrejo/64bits/debian//lib/gambas3"
> >  /usr/bin/install -c -m 644 'gb.xml.rpc.component'
> > '/home/jredrejo/64bits/debian//lib/gambas3/gb.xml.rpc.component'
> > make  install-data-hook
> > make[5]: Entering directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> > Compiling the gb.xml.rpc project...
> > gb.xml.rpc
> > gbi3: warning: component gb.xml.rpc not found
> > /home/jredrejo/64bits/gb.xml/src/rpc/gb.xml.rpc/RpcClient.class:110:
> > Unknown identifier: XmlReader
> >
> > Creating the information files for gb.xml.rpc component...
> > gb.xml.rpc
> > make[5]: *** [install-data-hook] Segmentation fault
> > make[5]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> > make[4]: *** [install-data-am] Error 2
> > make[4]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> > make[3]: *** [install-am] Error 2
> > make[3]: Leaving directory `/home/jredrejo/64bits/gb.xml/src/rpc'
> > make[2]: *** [install-recursive] Error 1
> > make[2]: Leaving directory `/home/jredrejo/64bits/gb.xml/src'
> > make[1]: *** [install-recursive] Error 1
> > make[1]: Leaving directory `/home/jredrejo/64bits/gb.xml'
> > make: *** [install-recursive] Error 1
> >
>
> Interesting, as gb.xml.rpc is only a Gambas component. Can you get the
> backtrace with gdb?
>
> --
> Benoit Minisini
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080114/7acbc636/attachment.html>

From dcamposf at ...176...  Mon Jan 14 15:19:57 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Mon, 14 Jan 2008 15:19:57 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801140458y332dccd4hed06452f3f87bff8@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801121615.19121.gambas@...1...>
	<8eb28a500801121012r3d500a07r804b0f440cfbd7df@...178...>
	<200801122044.35247.gambas@...1...>
	<8eb28a500801140458y332dccd4hed06452f3f87bff8@...178...>
Message-ID: <7259b5ae0801140619i141dc04icb38d2837c60a6b1@...178...>

Hi Jos? Luis:

Please try to  call external C functions, first in 32bits system to
check it works, then in a 64bits system. I suspect this should fail...

Daniel



From jredrejo at ...176...  Mon Jan 14 15:45:26 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Mon, 14 Jan 2008 15:45:26 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <7259b5ae0801140619i141dc04icb38d2837c60a6b1@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801121615.19121.gambas@...1...>
	<8eb28a500801121012r3d500a07r804b0f440cfbd7df@...178...>
	<200801122044.35247.gambas@...1...>
	<8eb28a500801140458y332dccd4hed06452f3f87bff8@...178...>
	<7259b5ae0801140619i141dc04icb38d2837c60a6b1@...178...>
Message-ID: <8eb28a500801140645r31ac55d0le03d3e271155ce34@...178...>

Do you have an example of it?

2008/1/14, Daniel Campos <dcamposf at ...176...>:
>
> Hi Jos? Luis:
>
> Please try to  call external C functions, first in 32bits system to
> check it works, then in a 64bits system. I suspect this should fail...
>
> Daniel
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080114/91aadf06/attachment.html>

From dcamposf at ...176...  Mon Jan 14 16:09:08 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Mon, 14 Jan 2008 16:09:08 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <8eb28a500801140645r31ac55d0le03d3e271155ce34@...178...>
References: <200801091614.44194.gambas@...1...>
	<200801121615.19121.gambas@...1...>
	<8eb28a500801121012r3d500a07r804b0f440cfbd7df@...178...>
	<200801122044.35247.gambas@...1...>
	<8eb28a500801140458y332dccd4hed06452f3f87bff8@...178...>
	<7259b5ae0801140619i141dc04icb38d2837c60a6b1@...178...>
	<8eb28a500801140645r31ac55d0le03d3e271155ce34@...178...>
Message-ID: <7259b5ae0801140709y3a5e847br8cc4362f619d89f5@...178...>

You can test that for example, is a simple console program that calls
GTK+ to create a window and show it. if this simple example works we
can test more complicated calls.

Daniel


2008/1/14, Jos? Luis Redrejo <jredrejo at ...176...>:
> Do you have an example of it?
>
> 2008/1/14, Daniel Campos <dcamposf at ...176...>:
> >
> > Hi Jos? Luis:
> >
> > Please try to  call external C functions, first in 32bits system to
> > check it works, then in a 64bits system. I suspect this should fail...
> >
> > Daniel
> >
> >
> -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> >
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > Gambas-devel mailing list
> > Gambas-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gambas-devel
> >
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SysCall-0.0.1.tar.gz
Type: application/x-gzip
Size: 7517 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080114/35f9da69/attachment.bin>

From gambas at ...1...  Mon Jan 14 17:49:35 2008
From: gambas at ...1... (Benoit Minisini)
Date: Mon, 14 Jan 2008 17:49:35 +0100
Subject: [Gambas-devel] [Gambas-user] 64 bits version
In-Reply-To: <7259b5ae0801140709y3a5e847br8cc4362f619d89f5@...178...>
References: <200801091614.44194.gambas@...1...>
	<8eb28a500801140645r31ac55d0le03d3e271155ce34@...178...>
	<7259b5ae0801140709y3a5e847br8cc4362f619d89f5@...178...>
Message-ID: <200801141749.35380.gambas@...1...>

On lundi 14 janvier 2008, Daniel Campos wrote:
> You can test that for example, is a simple console program that calls
> GTK+ to create a window and show it. if this simple example works we
> can test more complicated calls.
>
> Daniel
>

Don't be too optimistic :-) Loading class does not work yet, it crashed.

As for calling external function, it may be not possible as apparently calling 
convention changed between 32 bits and 64 bits. Now registers seems to be 
used by default. Maybe another trick will be needed.

There is a lot of work to do in your components too, so that they are 64 bits 
aware. I did the work just for gb.compress.zlib. But if you could do it, I 
will be able to concentrate on other more difficult things. :-)

Mainly, you have to:

* Replace 'long' datatypes by 'int' if just a 32 bits integer is needed.

* Replace 'long' by 'intptr_t' if you are storing a pointer.

* Replace 'long long' by 'int64_t'.

* Fix the other casting warnings.

* Fix the use of GB_STREAM structure as I did in gb.compress.zlib. I will 
declare GB_STREAM without the 'free' members, so that it will be used exactly 
as GB_BASE. So you will have to declare your own stream structure. Something 
like:

typedef
  struct {
    GB_STREAM_BASE stream;
    void *myHandle;
    ...
    }
  MY_STREAM;

I will fix the declaration of GB_STREAM soon.

* Surely other things I didn't think now. :-)

Regards,

-- 
Benoit Minisini



From scatman at ...571...  Mon Jan 14 19:09:31 2008
From: scatman at ...571... (scatman)
Date: Mon, 14 Jan 2008 19:09:31 +0100
Subject: [Gambas-devel] Unable to load class file
Message-ID: <200801141909.31186.scatman@...571...>

Hello,

all examples comes up on my Gentoo with this error. 
Unable to load class file.
 
I have recompiled gtk+-2.12.5, glib-2.14.5 with debug and gambas with 
make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g".

Revision 970

Here the backtrace.

(gdb) r examples/examples/Basic/Collection/
Starting program: /usr/local/bin/gbx3 examples/examples/Basic/Collection/
warning: no loadable sections found in added symbol-file system-supplied DSO 
at 0x7fff723fd000
Warning: The 64 bits version of Gambas is not stable yet.
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) bt
#0  0x00002ad63872fe67 in ?? () from /lib64/ld-linux-x86-64.so.2
#1  0x00002ad63872bcf6 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x00002ad63872f7bb in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x00002ad638bbafcb in ?? () from /lib/libdl.so.2
#4  0x00002ad63872bcf6 in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x00002ad638bbb35d in ?? () from /lib/libdl.so.2
#6  0x00002ad638bbaf31 in dlopen () from /lib/libdl.so.2
#7  0x00002ad63b1ef94c in g_module_open () from /usr/lib/libgmodule-2.0.so.0
#8  0x00002ad639e412dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#9  0x00002ad63afd791c in g_type_module_use () 
from /usr/lib/libgobject-2.0.so.0
#10 0x00002ad639e4115a in gtk_theme_engine_get () 
from /usr/lib/libgtk-x11-2.0.so.0
#11 0x00002ad639dc43dd in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00002ad639dc6402 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x00002ad639dc6f49 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x00002ad639dc73b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x00002ad639dc7513 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x00002ad639dc718c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x00002ad639dc73b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#18 0x00002ad639dc7513 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#19 0x00002ad639dc78a4 in gtk_rc_reparse_all_for_settings ()
   from /usr/lib/libgtk-x11-2.0.so.0
#20 0x00002ad639de32ef in gtk_settings_get_for_screen ()
   from /usr/lib/libgtk-x11-2.0.so.0
#21 0x00002ad639dfdfc9 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#22 0x00002ad63afd677c in g_type_create_instance () 
from /usr/lib/libgobject-2.0.so.0
#23 0x00002ad63afbbfbd in ?? () from /usr/lib/libgobject-2.0.so.0
#24 0x00002ad63afbc5be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#25 0x00002ad63afbd0b0 in g_object_new_valist () 
from /usr/lib/libgobject-2.0.so.0
#26 0x00002ad63afbd1f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#27 0x00002ad639e98aa5 in gtk_widget_get_default_style ()
   from /usr/lib/libgtk-x11-2.0.so.0
#28 0x00002ad639ea289d in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#29 0x00002ad63afd65d1 in g_type_create_instance () 
from /usr/lib/libgobject-2.0.so.0
#30 0x00002ad63afbbfbd in ?? () from /usr/lib/libgobject-2.0.so.0
#31 0x00002ad63afbc5be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#32 0x00002ad63afbd0b0 in g_object_new_valist () 
from /usr/lib/libgobject-2.0.so.0
#33 0x00002ad63afbd1f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#34 0x00002ad639eaf6a6 in gtk_window_new () 
from /usr/lib/libgtk-x11-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#35 0x00002ad639e51672 in gtk_tooltips_force_window ()
   from /usr/lib/libgtk-x11-2.0.so.0
#36 0x00002ad63afd677c in g_type_create_instance () 
from /usr/lib/libgobject-2.0.so.0
#37 0x00002ad63afbbfbd in ?? () from /usr/lib/libgobject-2.0.so.0
#38 0x00002ad63afbc5be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#39 0x00002ad63afbd0b0 in g_object_new_valist () 
from /usr/lib/libgobject-2.0.so.0
#40 0x00002ad63afbd1f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#41 0x00002ad6399a85c3 in gApplication::init (argc=<value optimized out>,
    argv=<value optimized out>) at gapplication.cpp:293
#42 0x00002ad6399a747b in my_main (argc=0x0, argv=0x7fff72386e58) at 
main.cpp:299
#43 0x000000000041b52e in main (argc=1, argv=0x7fff72386e58) at gbx.c:297

(gdb) l
113       EVENT_exit();
114       FILE_exit();
115       STRING_exit();
116             ERROR_clear();
117       STACK_exit();
118     }
119
120
121     int main(int argc, char **argv)
122     {

thanks



From scatman at ...571...  Tue Jan 15 21:53:02 2008
From: scatman at ...571... (scatman)
Date: Tue, 15 Jan 2008 21:53:02 +0100
Subject: [Gambas-devel] Unable to load class file rev 986
In-Reply-To: <200801141909.31186.scatman@...571...>
References: <200801141909.31186.scatman@...571...>
	(sfid-20080114_191012_323009_320EFA7D41092C5)
Message-ID: <200801152153.02315.scatman@...571...>

Am Montag, 14. Januar 2008 schrieb scatman:

> all examples comes up on my Gentoo with this error.
> Unable to load class file.
>
> I have recompiled gtk+-2.12.5, glib-2.14.5 with debug and gambas with
> make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g".
>
> Revision 970
>
> Here the backtrace.

rev 986

Starting program: /usr/local/bin/gbx3 examples/examples/Basic/Collection/
warning: no loadable sections found in added symbol-file system-supplied DSO 
at 0x7fffa0dfd000
Warning: The 64 bits version of Gambas is not stable yet.
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) bt
#0  0x00002ba109e9ce67 in ?? () from /lib64/ld-linux-x86-64.so.2
#1  0x00002ba109e98cf6 in ?? () from /lib64/ld-linux-x86-64.so.2
#2  0x00002ba109e9c7bb in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x00002ba10a327fcb in ?? () from /lib/libdl.so.2
#4  0x00002ba109e98cf6 in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x00002ba10a32835d in ?? () from /lib/libdl.so.2
#6  0x00002ba10a327f31 in dlopen () from /lib/libdl.so.2
#7  0x00002ba10c97794c in g_module_open () from /usr/lib/libgmodule-2.0.so.0
#8  0x00002ba10b5c92dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#9  0x00002ba10c75f91c in g_type_module_use () 
from /usr/lib/libgobject-2.0.so.0
#10 0x00002ba10b5c915a in gtk_theme_engine_get () 
from /usr/lib/libgtk-x11-2.0.so.0
#11 0x00002ba10b54c3dd in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00002ba10b54e402 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x00002ba10b54ef49 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x00002ba10b54f3b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x00002ba10b54f513 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x00002ba10b54f18c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x00002ba10b54f3b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#18 0x00002ba10b54f513 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#19 0x00002ba10b54f8a4 in gtk_rc_reparse_all_for_settings ()
   from /usr/lib/libgtk-x11-2.0.so.0
#20 0x00002ba10b56b2ef in gtk_settings_get_for_screen ()
   from /usr/lib/libgtk-x11-2.0.so.0
#21 0x00002ba10b585fc9 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#22 0x00002ba10c75e77c in g_type_create_instance ()
   from /usr/lib/libgobject-2.0.so.0
#23 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
#24 0x00002ba10c7445be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#25 0x00002ba10c7450b0 in g_object_new_valist () 
from /usr/lib/libgobject-2.0.so.0
#26 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#27 0x00002ba10b620aa5 in gtk_widget_get_default_style ()
   from /usr/lib/libgtk-x11-2.0.so.0
#28 0x00002ba10b62a89d in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#29 0x00002ba10c75e5d1 in g_type_create_instance ()
   from /usr/lib/libgobject-2.0.so.0
#30 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
#31 0x00002ba10c7445be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#32 0x00002ba10c7450b0 in g_object_new_valist () 
from /usr/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#33 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#34 0x00002ba10b6376a6 in gtk_window_new () 
from /usr/lib/libgtk-x11-2.0.so.0
#35 0x00002ba10b5d9672 in gtk_tooltips_force_window ()
   from /usr/lib/libgtk-x11-2.0.so.0
#36 0x00002ba10c75e77c in g_type_create_instance ()
   from /usr/lib/libgobject-2.0.so.0
#37 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
#38 0x00002ba10c7445be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#39 0x00002ba10c7450b0 in g_object_new_valist () 
from /usr/lib/libgobject-2.0.so.0
#40 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#41 0x00002ba10b12c715 in gApplication::init (argc=0x7fffa0c1a4ec,
    argv=0x7fffa0c1a4b0) at gapplication.cpp:293
#42 0x00002ba10b12af15 in my_main (argc=0x7fffa0c1a4ec, argv=0x7fffa0c1a6e8)
    at main.cpp:299
#43 0x000000000042bf7c in main (argc=1, argv=0x7fffa0c1a6e8) at gbx.c:297

(gdb) l
125
126       int i, n;
127       char *file = ".";
128       bool nopreload = FALSE;
129
130       MEMORY_init();
131       COMMON_init();
132       //STRING_init();
133
134             if (strcmp(argv[0], "gbr" GAMBAS_VERSION_STRING) == 0)




From dcamposf at ...176...  Wed Jan 16 11:42:41 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Wed, 16 Jan 2008 11:42:41 +0100
Subject: [Gambas-devel] Unable to load class file rev 986
In-Reply-To: <200801152153.02315.scatman@...571...>
References: <200801141909.31186.scatman@...571...>
	<200801152153.02315.scatman@...571...>
Message-ID: <7259b5ae0801160242v36831111lba82b0f2ebdfab96@...178...>

Class loading will be broken some days, as Benoit said, he's fixing a
lot of things for 64 bits :-)

2008/1/15, scatman <scatman at ...571...>:
> Am Montag, 14. Januar 2008 schrieb scatman:
>
> > all examples comes up on my Gentoo with this error.
> > Unable to load class file.
> >
> > I have recompiled gtk+-2.12.5, glib-2.14.5 with debug and gambas with
> > make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g".
> >
> > Revision 970
> >
> > Here the backtrace.
>
> rev 986
>
> Starting program: /usr/local/bin/gbx3 examples/examples/Basic/Collection/
> warning: no loadable sections found in added symbol-file system-supplied DSO
> at 0x7fffa0dfd000
> Warning: The 64 bits version of Gambas is not stable yet.
> [Thread debugging using libthread_db enabled]
> Error while reading shared library symbols:
> Cannot find new threads: generic error
> Cannot find new threads: generic error
> (gdb) bt
> #0  0x00002ba109e9ce67 in ?? () from /lib64/ld-linux-x86-64.so.2
> #1  0x00002ba109e98cf6 in ?? () from /lib64/ld-linux-x86-64.so.2
> #2  0x00002ba109e9c7bb in ?? () from /lib64/ld-linux-x86-64.so.2
> #3  0x00002ba10a327fcb in ?? () from /lib/libdl.so.2
> #4  0x00002ba109e98cf6 in ?? () from /lib64/ld-linux-x86-64.so.2
> #5  0x00002ba10a32835d in ?? () from /lib/libdl.so.2
> #6  0x00002ba10a327f31 in dlopen () from /lib/libdl.so.2
> #7  0x00002ba10c97794c in g_module_open () from /usr/lib/libgmodule-2.0.so.0
> #8  0x00002ba10b5c92dc in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #9  0x00002ba10c75f91c in g_type_module_use ()
> from /usr/lib/libgobject-2.0.so.0
> #10 0x00002ba10b5c915a in gtk_theme_engine_get ()
> from /usr/lib/libgtk-x11-2.0.so.0
> #11 0x00002ba10b54c3dd in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #12 0x00002ba10b54e402 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #13 0x00002ba10b54ef49 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #14 0x00002ba10b54f3b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #15 0x00002ba10b54f513 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #16 0x00002ba10b54f18c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #17 0x00002ba10b54f3b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #18 0x00002ba10b54f513 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> ---Type <return> to continue, or q <return> to quit---
> #19 0x00002ba10b54f8a4 in gtk_rc_reparse_all_for_settings ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #20 0x00002ba10b56b2ef in gtk_settings_get_for_screen ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #21 0x00002ba10b585fc9 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #22 0x00002ba10c75e77c in g_type_create_instance ()
>    from /usr/lib/libgobject-2.0.so.0
> #23 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
> #24 0x00002ba10c7445be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
> #25 0x00002ba10c7450b0 in g_object_new_valist ()
> from /usr/lib/libgobject-2.0.so.0
> #26 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
> #27 0x00002ba10b620aa5 in gtk_widget_get_default_style ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #28 0x00002ba10b62a89d in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #29 0x00002ba10c75e5d1 in g_type_create_instance ()
>    from /usr/lib/libgobject-2.0.so.0
> #30 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
> #31 0x00002ba10c7445be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
> #32 0x00002ba10c7450b0 in g_object_new_valist ()
> from /usr/lib/libgobject-2.0.so.0
> ---Type <return> to continue, or q <return> to quit---
> #33 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
> #34 0x00002ba10b6376a6 in gtk_window_new ()
> from /usr/lib/libgtk-x11-2.0.so.0
> #35 0x00002ba10b5d9672 in gtk_tooltips_force_window ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #36 0x00002ba10c75e77c in g_type_create_instance ()
>    from /usr/lib/libgobject-2.0.so.0
> #37 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
> #38 0x00002ba10c7445be in g_object_newv () from /usr/lib/libgobject-2.0.so.0
> #39 0x00002ba10c7450b0 in g_object_new_valist ()
> from /usr/lib/libgobject-2.0.so.0
> #40 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
> #41 0x00002ba10b12c715 in gApplication::init (argc=0x7fffa0c1a4ec,
>     argv=0x7fffa0c1a4b0) at gapplication.cpp:293
> #42 0x00002ba10b12af15 in my_main (argc=0x7fffa0c1a4ec, argv=0x7fffa0c1a6e8)
>     at main.cpp:299
> #43 0x000000000042bf7c in main (argc=1, argv=0x7fffa0c1a6e8) at gbx.c:297
>
> (gdb) l
> 125
> 126       int i, n;
> 127       char *file = ".";
> 128       bool nopreload = FALSE;
> 129
> 130       MEMORY_init();
> 131       COMMON_init();
> 132       //STRING_init();
> 133
> 134             if (strcmp(argv[0], "gbr" GAMBAS_VERSION_STRING) == 0)
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>



From gambas at ...1...  Wed Jan 16 12:47:47 2008
From: gambas at ...1... (Benoit Minisini)
Date: Wed, 16 Jan 2008 12:47:47 +0100
Subject: [Gambas-devel] Unable to load class file rev 986
In-Reply-To: <200801152153.02315.scatman@...571...>
References: <200801141909.31186.scatman@...571...>
	<200801152153.02315.scatman@...571...>
Message-ID: <200801161247.47800.gambas@...1...>

On mardi 15 janvier 2008, scatman wrote:
> Am Montag, 14. Januar 2008 schrieb scatman:
> > all examples comes up on my Gentoo with this error.
> > Unable to load class file.
> >
> > I have recompiled gtk+-2.12.5, glib-2.14.5 with debug and gambas with
> > make "CFLAGS=-O0 -g" "CXXFLAGS=-O0 -g".
> >
> > Revision 970
> >
> > Here the backtrace.
>
> rev 986
>
> Starting program: /usr/local/bin/gbx3 examples/examples/Basic/Collection/
> warning: no loadable sections found in added symbol-file system-supplied
> DSO at 0x7fffa0dfd000
> Warning: The 64 bits version of Gambas is not stable yet.
> [Thread debugging using libthread_db enabled]
> Error while reading shared library symbols:
> Cannot find new threads: generic error
> Cannot find new threads: generic error
> (gdb) bt
> #0  0x00002ba109e9ce67 in ?? () from /lib64/ld-linux-x86-64.so.2
> #1  0x00002ba109e98cf6 in ?? () from /lib64/ld-linux-x86-64.so.2
> #2  0x00002ba109e9c7bb in ?? () from /lib64/ld-linux-x86-64.so.2
> #3  0x00002ba10a327fcb in ?? () from /lib/libdl.so.2
> #4  0x00002ba109e98cf6 in ?? () from /lib64/ld-linux-x86-64.so.2
> #5  0x00002ba10a32835d in ?? () from /lib/libdl.so.2
> #6  0x00002ba10a327f31 in dlopen () from /lib/libdl.so.2
> #7  0x00002ba10c97794c in g_module_open () from
> /usr/lib/libgmodule-2.0.so.0 #8  0x00002ba10b5c92dc in ?? () from
> /usr/lib/libgtk-x11-2.0.so.0
> #9  0x00002ba10c75f91c in g_type_module_use ()
> from /usr/lib/libgobject-2.0.so.0
> #10 0x00002ba10b5c915a in gtk_theme_engine_get ()
> from /usr/lib/libgtk-x11-2.0.so.0
> #11 0x00002ba10b54c3dd in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #12 0x00002ba10b54e402 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #13 0x00002ba10b54ef49 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #14 0x00002ba10b54f3b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #15 0x00002ba10b54f513 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #16 0x00002ba10b54f18c in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #17 0x00002ba10b54f3b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #18 0x00002ba10b54f513 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> ---Type <return> to continue, or q <return> to quit---
> #19 0x00002ba10b54f8a4 in gtk_rc_reparse_all_for_settings ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #20 0x00002ba10b56b2ef in gtk_settings_get_for_screen ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #21 0x00002ba10b585fc9 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #22 0x00002ba10c75e77c in g_type_create_instance ()
>    from /usr/lib/libgobject-2.0.so.0
> #23 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
> #24 0x00002ba10c7445be in g_object_newv () from
> /usr/lib/libgobject-2.0.so.0 #25 0x00002ba10c7450b0 in g_object_new_valist
> ()
> from /usr/lib/libgobject-2.0.so.0
> #26 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
> #27 0x00002ba10b620aa5 in gtk_widget_get_default_style ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #28 0x00002ba10b62a89d in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #29 0x00002ba10c75e5d1 in g_type_create_instance ()
>    from /usr/lib/libgobject-2.0.so.0
> #30 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
> #31 0x00002ba10c7445be in g_object_newv () from
> /usr/lib/libgobject-2.0.so.0 #32 0x00002ba10c7450b0 in g_object_new_valist
> ()
> from /usr/lib/libgobject-2.0.so.0
> ---Type <return> to continue, or q <return> to quit---
> #33 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
> #34 0x00002ba10b6376a6 in gtk_window_new ()
> from /usr/lib/libgtk-x11-2.0.so.0
> #35 0x00002ba10b5d9672 in gtk_tooltips_force_window ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #36 0x00002ba10c75e77c in g_type_create_instance ()
>    from /usr/lib/libgobject-2.0.so.0
> #37 0x00002ba10c743fbd in ?? () from /usr/lib/libgobject-2.0.so.0
> #38 0x00002ba10c7445be in g_object_newv () from
> /usr/lib/libgobject-2.0.so.0 #39 0x00002ba10c7450b0 in g_object_new_valist
> ()
> from /usr/lib/libgobject-2.0.so.0
> #40 0x00002ba10c7451f1 in g_object_new () from /usr/lib/libgobject-2.0.so.0
> #41 0x00002ba10b12c715 in gApplication::init (argc=0x7fffa0c1a4ec,
>     argv=0x7fffa0c1a4b0) at gapplication.cpp:293
> #42 0x00002ba10b12af15 in my_main (argc=0x7fffa0c1a4ec,
> argv=0x7fffa0c1a6e8) at main.cpp:299
> #43 0x000000000042bf7c in main (argc=1, argv=0x7fffa0c1a6e8) at gbx.c:297
>
> (gdb) l
> 125
> 126       int i, n;
> 127       char *file = ".";
> 128       bool nopreload = FALSE;
> 129
> 130       MEMORY_init();
> 131       COMMON_init();
> 132       //STRING_init();
> 133
> 134             if (strcmp(argv[0], "gbr" GAMBAS_VERSION_STRING) == 0)
>
>

But why does the program stop? You don't have any segmentation fault in the 
messages...

-- 
Benoit Minisini



From scatman at ...571...  Wed Jan 16 17:38:26 2008
From: scatman at ...571... (scatman)
Date: Wed, 16 Jan 2008 17:38:26 +0100
Subject: [Gambas-devel] Unable to load class file rev 986
In-Reply-To: <200801161247.47800.gambas@...1...>
References: <200801141909.31186.scatman@...571...>
	<200801152153.02315.scatman@...571...>
	<200801161247.47800.gambas@...1...>
	(sfid-20080116_152831_611269_F66CCA0DE336D872)
Message-ID: <200801161738.26652.scatman@...571...>

Am Mittwoch, 16. Januar 2008 schrieb Benoit Minisini:

>
> But why does the program stop? You don't have any segmentation fault in
> the messages...

Gambas stop for example Blights with
This application has raised an unexpected error and must abort.
[2] Cannot load class ?win1? Unable to load class file.?

example Embedder
ERROR: #2: Cannot load class 'FMain': Unable to load class file

All the same Error with all Examples.

If you want, i can strace gbx3.
Mayby ist helps...



From gambas at ...1...  Wed Jan 16 17:41:58 2008
From: gambas at ...1... (Benoit Minisini)
Date: Wed, 16 Jan 2008 17:41:58 +0100
Subject: [Gambas-devel] Unable to load class file rev 986
In-Reply-To: <200801161738.26652.scatman@...571...>
References: <200801141909.31186.scatman@...571...>
	<200801161247.47800.gambas@...1...>
	<200801161738.26652.scatman@...571...>
Message-ID: <200801161741.59004.gambas@...1...>

On mercredi 16 janvier 2008, scatman wrote:
> Am Mittwoch, 16. Januar 2008 schrieb Benoit Minisini:
> > But why does the program stop? You don't have any segmentation fault in
> > the messages...
>
> Gambas stop for example Blights with
> This application has raised an unexpected error and must abort.
> [2] Cannot load class ?win1? Unable to load class file.?
>
> example Embedder
> ERROR: #2: Cannot load class 'FMain': Unable to load class file
>
> All the same Error with all Examples.
>
> If you want, i can strace gbx3.
> Mayby ist helps...
>

That means that you must compile the project first! To do that, 
run 'gbc3 -agt' inside the project directory.

On Ubuntu 64 bits, now, I can compile everything, install everything, and run 
the IDE. Maybe you could try.

Regards,

-- 
Benoit Minisini



From scatman at ...571...  Wed Jan 16 18:39:03 2008
From: scatman at ...571... (scatman)
Date: Wed, 16 Jan 2008 18:39:03 +0100
Subject: [Gambas-devel] Unable to load class file rev 986
In-Reply-To: <200801161741.59004.gambas@...1...>
References: <200801141909.31186.scatman@...571...>
	<200801161738.26652.scatman@...571...>
	<200801161741.59004.gambas@...1...>
	(sfid-20080116_174436_922538_ABD3C9843F9D4D51)
Message-ID: <200801161839.03926.scatman@...571...>

Am Mittwoch, 16. Januar 2008 schrieb Benoit Minisini:

> That means that you must compile the project first! To do that,
> run 'gbc3 -agt' inside the project directory.
>
> On Ubuntu 64 bits, now, I can compile everything, install everything, and
> run the IDE. Maybe you could try.

wow, Great. It works now ;)

Many Thanks



From scatman at ...571...  Thu Jan 17 17:16:10 2008
From: scatman at ...571... (scatman)
Date: Thu, 17 Jan 2008 17:16:10 +0100
Subject: [Gambas-devel] configure failed
Message-ID: <200801171716.10304.scatman@...571...>

Hello,

rev 1000 and 1002.
gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)

the haeder files from libffi are stored in Gentoo under /usr/include/libffi. 
The configure Script only looking in /usr/include for ffi.h and  
ffitarget.h and configure failed. Ok, no Problem. I make Symlinks 
to /usr/include and start configure again. ffi.h and ffitarget.h are found 
and configure finished. 
But make gives me now this error.

########################################################

array.o gbx3-gbx_c_process.o gbx3-gbx_c_subcollection.o gbx3-gbx_c_string.o 
gbx3-gbx_component.o gbx3-gbx_extern.o gbx3-gbx_print.o gbx3-gbx_c_enum.o 
gbx3-gbx_c_timer.o gbx3-gbx_c_quote.o  -lm -ldl
gbx3-gbx_extern.o: In function `EXTERN_call':
/home/test/64bits/main/gbx/gbx_extern.c:338: undefined reference to 
`ffi_prep_cif'
/home/test/64bits/main/gbx/gbx_extern.c:341: undefined reference to 
`ffi_call'
gbx3-gbx_extern.o:(.rodata+0x50): undefined reference to `ffi_type_void'
gbx3-gbx_extern.o:(.rodata+0x58): undefined reference to `ffi_type_sint32'
gbx3-gbx_extern.o:(.rodata+0x60): undefined reference to `ffi_type_sint32'
gbx3-gbx_extern.o:(.rodata+0x68): undefined reference to `ffi_type_sint32'
gbx3-gbx_extern.o:(.rodata+0x70): undefined reference to `ffi_type_sint32'
gbx3-gbx_extern.o:(.rodata+0x78): undefined reference to `ffi_type_sint64'
gbx3-gbx_extern.o:(.rodata+0x80): undefined reference to `ffi_type_float'
gbx3-gbx_extern.o:(.rodata+0x88): undefined reference to `ffi_type_double'
gbx3-gbx_extern.o:(.rodata+0x90): undefined reference to `ffi_type_void'
gbx3-gbx_extern.o:(.rodata+0x98): undefined reference to `ffi_type_pointer'
gbx3-gbx_extern.o:(.rodata+0xa0): undefined reference to `ffi_type_pointer'
gbx3-gbx_extern.o:(.rodata+0xa8): undefined reference to `ffi_type_void'
gbx3-gbx_extern.o:(.rodata+0xb0): undefined reference to `ffi_type_void'
gbx3-gbx_extern.o:(.rodata+0xb8): undefined reference to `ffi_type_void'
gbx3-gbx_extern.o:(.rodata+0xc0): undefined reference to `ffi_type_void'
gbx3-gbx_extern.o:(.rodata+0xc8): undefined reference to `ffi_type_pointer'
gbx3-gbx_extern.o:(.rodata+0xd0): undefined reference to `ffi_type_pointer'
collect2: ld returned 1 exit status
make[4]: *** [gbx3] Error 1

Thanks




From gambas at ...1...  Thu Jan 17 17:32:53 2008
From: gambas at ...1... (Benoit Minisini)
Date: Thu, 17 Jan 2008 17:32:53 +0100
Subject: [Gambas-devel] configure failed
In-Reply-To: <200801171716.10304.scatman@...571...>
References: <200801171716.10304.scatman@...571...>
Message-ID: <200801171732.54066.gambas@...1...>

On jeudi 17 janvier 2008, scatman wrote:
> Hello,
>
> rev 1000 and 1002.
> gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)
>
> the haeder files from libffi are stored in Gentoo under
> /usr/include/libffi. The configure Script only looking in /usr/include for
> ffi.h and
> ffitarget.h and configure failed. Ok, no Problem. I make Symlinks
> to /usr/include and start configure again. ffi.h and ffitarget.h are found
> and configure finished.
> But make gives me now this error.
>

On Mandriva, the ffi.h and ffitarget.h are include files that are part of gcc, 
and are installed inside a specific gcc directory that depends on the gcc 
version. And they are automatically reachable at compilation time.

I will modify then configuration so that the include files are searched.

Regards,

-- 
Benoit Minisini



From scatman at ...571...  Thu Jan 17 19:38:15 2008
From: scatman at ...571... (scatman)
Date: Thu, 17 Jan 2008 19:38:15 +0100
Subject: [Gambas-devel] changelog
Message-ID: <200801171938.15696.scatman@...571...>

it is  possibly  to make a Changelog for svn 64bit Version?

Thanks



From gambas at ...1...  Thu Jan 17 19:46:18 2008
From: gambas at ...1... (Benoit Minisini)
Date: Thu, 17 Jan 2008 19:46:18 +0100
Subject: [Gambas-devel] changelog
In-Reply-To: <200801171938.15696.scatman@...571...>
References: <200801171938.15696.scatman@...571...>
Message-ID: <200801171946.18729.gambas@...1...>

On jeudi 17 janvier 2008, scatman wrote:
> it is  possibly  to make a Changelog for svn 64bit Version?
>
> Thanks
>

Just look at the subversion logs. I make ChangeLog when releasing a version 
from them.

Regards,

-- 
Benoit Minisini



From gambas at ...1...  Thu Jan 17 20:00:43 2008
From: gambas at ...1... (Benoit Minisini)
Date: Thu, 17 Jan 2008 20:00:43 +0100
Subject: [Gambas-devel] 64bit autoconf requirement
In-Reply-To: <478A5524.5060402@...572...>
References: <478A5524.5060402@...572...>
Message-ID: <200801172000.43602.gambas@...1...>

On dimanche 13 janvier 2008, Ron wrote:
> Hi Benoit,
>
> The 64bits gambas  trunk uses a different autoconf as the 32bits version
> does.
> It needs 2.61 to support the no-recursive flag, CentOS 5.1 and RedHat
> RHEL5 still have 2.59-12, this means gambas cannot be compiled on those
> platforms
> without installing an unsupported package.
>
> Otherwise you get this error while running ./reconf
> /usr/bin/autoreconf: unrecognized option `--no-recursive'

I removed the use of this option.

>
> I have:
> [root at ...573... 64bits]# yum list installed|grep autoconf
> autoconf.noarch                          2.59-12
> installed
>
> I then compiled and installed autoconf 2.61 manually to be able to
> provide you with debug info for gambas 64 bits.
> Would be nice if the final release uses the old autoconf again to
> prevent compilation problems (if possible)

What prevents you from upgrading your OS?

>
> My ./configure run keeps failing with:
> ------- cut ---------
> ...
> ...
> === configuring in gb.sdl (/home/ron/build/gambas/64bits/gb.sdl)
> configure: running /bin/sh ./configure '--prefix=/usr/local'
> --cache-file=/dev/null --srcdir=.
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking build system type... x86_64-unknown-linux-gnu
> checking for style of include used by make... GNU
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking host system type... x86_64-unknown-linux-gnu
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
> checking for g++... no
> checking for c++... no
> checking for gpp... no
> checking for aCC... no
> checking for CC... no
> checking for cxx... no
> checking for cc++... no
> checking for cl.exe... no
> checking for FCC... no
> checking for KCC... no
> checking for RCC... no
> checking for xlC_r... no
> checking for xlC... no
> checking whether we are using the GNU C++ compiler... no
> checking whether g++ accepts -g... no
> checking dependency style of g++... none
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether ln -s works... yes
> checking whether make sets $(MAKE)... (cached) yes
> checking for setenv... yes
> checking for unsetenv... yes
> checking for getdomainname... yes
> checking for getpt... yes
> checking for ccache... no
> checking for main in -lm... yes
> checking for main in -lz... yes
> checking for main in -lgcc_s... yes
> checking for main in -lstdc++... no
> checking target system... LINUX
> checking which extension is used for shared libraries... .so
> checking for threading compiler options... -D_REENTRANT
> checking for threading linker options... -lpthread
> checking for mathematic libraries... -lm
> checking CFLAGS for gcc -fvisibility=hidden... -fvisibility=hidden
> checking for a sed that does not truncate output... /bin/sed
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for /usr/bin/ld option to reload object files... -r
> checking for BSD-compatible nm... /usr/bin/nm -B
> checking how to recognize dependent libraries... pass_all
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking dlfcn.h usability... yes
> checking dlfcn.h presence... yes
> checking for dlfcn.h... yes
> checking for g77... no
> checking for xlf... no
> checking for f77... no
> checking for frt... no
> checking for pgf77... no
> checking for cf77... no
> checking for fort77... no
> checking for fl32... no
> checking for af77... no
> checking for xlf90... no
> checking for f90... no
> checking for pgf90... no
> checking for pghpf... no
> checking for epcf90... no
> checking for gfortran... no
> checking for g95... no
> checking for xlf95... no
> checking for f95... no
> checking for fort... no
> checking for ifort... no
> checking for ifc... no
> checking for efc... no
> checking for pgf95... no
> checking for lf95... no
> checking for ftn... no
> checking whether we are using the GNU Fortran 77 compiler... no
> checking whether  accepts -g... no
> checking the maximum length of command line arguments... 98304
> checking command to parse /usr/bin/nm -B output from gcc object... ok
> checking for objdir... .libs
> checking for ar... ar
> checking for ranlib... ranlib
> checking for strip... strip
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC
> checking if gcc PIC flag -fPIC works... yes
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports
> shared libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking for shl_load... no
> checking for shl_load in -ldld... no
> checking for dlopen... no
> checking for dlopen in -ldl... yes
> checking whether a program can dlopen itself... yes
> checking whether a statically linked program can dlopen itself... no
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... no
> configure: creating libtool
> appending configuration tag "CXX" to libtool
> appending configuration tag "F77" to libtool
> checking for X... libraries /usr/lib64, headers
> checking whether -R must be followed by a space... neither works
> checking for gethostbyname... yes
> checking for connect... yes
> checking for remove... yes
> checking for shmat... yes
> checking for IceConnectionNumber in -lICE... yes
> ./configure: line 21896: syntax error near unexpected token `1.2.8,'
> ./configure: line 21896: `GB_PATH_SDL(1.2.8, , touch DISABLED)'
> configure: error: ./configure failed for gb.sdl
> ---------- cut -------------
>
> Any idea? Or local problem...

Not really, maybe Laurent. Did you install all needed SDL development 
packages?

Regards,

-- 
Benoit Minisini



From gambas at ...1...  Thu Jan 17 22:37:05 2008
From: gambas at ...1... (Benoit Minisini)
Date: Thu, 17 Jan 2008 22:37:05 +0100
Subject: [Gambas-devel] 64 bits branch merge
Message-ID: <200801172237.05659.gambas@...1...>

Hi,

The 64 bits branch has been merged in the trunk. So don't modify it anymore, 
work directly on trunk!

Regards,

-- 
Benoit Minisini



From gambas at ...1...  Thu Jan 17 22:45:20 2008
From: gambas at ...1... (Benoit Minisini)
Date: Thu, 17 Jan 2008 22:45:20 +0100
Subject: [Gambas-devel] 64 bits branch merge
In-Reply-To: <200801172237.05659.gambas@...1...>
References: <200801172237.05659.gambas@...1...>
Message-ID: <200801172245.20495.gambas@...1...>

On jeudi 17 janvier 2008, Benoit Minisini wrote:
> Hi,
>
> The 64 bits branch has been merged in the trunk. So don't modify it
> anymore, work directly on trunk!
>
> Regards,

Now I'm doing the same merge for the 2.0 branches, so that we have a 64 bits 
version of Gambas 2!

-- 
Benoit Minisini



From sourceforge-raindog2 at ...19...  Thu Jan 17 23:04:16 2008
From: sourceforge-raindog2 at ...19... (Rob)
Date: Thu, 17 Jan 2008 17:04:16 -0500
Subject: [Gambas-devel] 64 bits branch merge
In-Reply-To: <200801172245.20495.gambas@...1...>
References: <200801172237.05659.gambas@...1...>
	<200801172245.20495.gambas@...1...>
Message-ID: <200801171704.16633.sourceforge-raindog2@...19...>

On Thursday 17 January 2008 16:45, Benoit Minisini wrote:
> Now I'm doing the same merge for the 2.0 branches, so that we have
> a 64 bits version of Gambas 2!

Sweet! You managed to do it without changing the bytecode format?

Rob



From gambas at ...1...  Thu Jan 17 23:15:43 2008
From: gambas at ...1... (Benoit Minisini)
Date: Thu, 17 Jan 2008 23:15:43 +0100
Subject: [Gambas-devel] 64 bits branch merge
In-Reply-To: <200801171704.16633.sourceforge-raindog2@...19...>
References: <200801172237.05659.gambas@...1...>
	<200801172245.20495.gambas@...1...>
	<200801171704.16633.sourceforge-raindog2@...19...>
Message-ID: <200801172315.44331.gambas@...1...>

On jeudi 17 janvier 2008, Rob wrote:
> On Thursday 17 January 2008 16:45, Benoit Minisini wrote:
> > Now I'm doing the same merge for the 2.0 branches, so that we have
> > a 64 bits version of Gambas 2!
>
> Sweet! You managed to do it without changing the bytecode format?
>
> Rob
>

The bytecode is not the problem there. But there are little flaws in the 
object file format that cannot be fixed without changing it.

The main consequence is that if you use the Pointer datatype, you must 
recompile your project if you go from a 32 bits OS to a 64 bits OS, or the 
contrary. 

Gambas executable that do not use the Pointer datatype can run indifferently 
on 32 bits OS or 64 bits OS.

Note that 64 bits interpreter use more memory than the 32 bits one, and that 
loading classes is slower. Because the object file format was designed with 
32 bits pointer in mind, not 64 bits.

Regards,

-- 
Benoit Minisini



From dcamposf at ...176...  Fri Jan 18 00:36:58 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Fri, 18 Jan 2008 00:36:58 +0100
Subject: [Gambas-devel] 64 bits branch merge
In-Reply-To: <200801172245.20495.gambas@...1...>
References: <200801172237.05659.gambas@...1...>
	<200801172245.20495.gambas@...1...>
Message-ID: <7259b5ae0801171536q65b6c902j14fab0a91aaef0ad@...178...>

>
> Now I'm doing the same merge for the 2.0 branches, so that we have a 64 bits
> version of Gambas 2!
>

Anyway it needs more testing, for example gb.net.curl seems to work,
but I'm surprised about it, theorically I'm using memory outside the
limits of of the STREAM definition, I must work on it next days....



From dcamposf at ...176...  Fri Jan 18 00:39:48 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Fri, 18 Jan 2008 00:39:48 +0100
Subject: [Gambas-devel] 64 bits branch merge
In-Reply-To: <200801172315.44331.gambas@...1...>
References: <200801172237.05659.gambas@...1...>
	<200801172245.20495.gambas@...1...>
	<200801171704.16633.sourceforge-raindog2@...19...>
	<200801172315.44331.gambas@...1...>
Message-ID: <7259b5ae0801171539h8625687h11d60365ca1dc85a@...178...>

>
> Note that 64 bits interpreter use more memory than the 32 bits one, and that
> loading classes is slower. Because the object file format was designed with
> 32 bits pointer in mind, not 64 bits.
>


The Poppler component seems to run faster for me now, after my 64bits
changes, and apart from this I don't see any big difference in
performance in a 64bits Ubuntu system, may be Valgrind can find it :-)
but not any problem for normal users and programmers

Daniel



From gambas at ...1...  Fri Jan 18 00:42:40 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 18 Jan 2008 00:42:40 +0100
Subject: [Gambas-devel] 64 bits branch merge
In-Reply-To: <7259b5ae0801171539h8625687h11d60365ca1dc85a@...178...>
References: <200801172237.05659.gambas@...1...>
	<200801172315.44331.gambas@...1...>
	<7259b5ae0801171539h8625687h11d60365ca1dc85a@...178...>
Message-ID: <200801180042.42580.gambas@...1...>

On vendredi 18 janvier 2008, Daniel Campos wrote:
> > Note that 64 bits interpreter use more memory than the 32 bits one, and
> > that loading classes is slower. Because the object file format was
> > designed with 32 bits pointer in mind, not 64 bits.
>
> The Poppler component seems to run faster for me now, after my 64bits
> changes, and apart from this I don't see any big difference in
> performance in a 64bits Ubuntu system, may be Valgrind can find it :-)
> but not any problem for normal users and programmers
>
> Daniel
>

The difference is not very important. Nobody will notice for sure.

-- 
Benoit Minisini



From gambas at ...1...  Fri Jan 18 00:46:02 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 18 Jan 2008 00:46:02 +0100
Subject: [Gambas-devel] 64 bits branch merge
In-Reply-To: <7259b5ae0801171536q65b6c902j14fab0a91aaef0ad@...178...>
References: <200801172237.05659.gambas@...1...>
	<200801172245.20495.gambas@...1...>
	<7259b5ae0801171536q65b6c902j14fab0a91aaef0ad@...178...>
Message-ID: <200801180046.03060.gambas@...1...>

On vendredi 18 janvier 2008, Daniel Campos wrote:
> > Now I'm doing the same merge for the 2.0 branches, so that we have a 64
> > bits version of Gambas 2!
>
> Anyway it needs more testing, for example gb.net.curl seems to work,
> but I'm surprised about it, theorically I'm using memory outside the
> limits of of the STREAM definition, I must work on it next days....
>

Ahem. If you need a bigger GB_STREAM, you should tell me!

At the moment, you can store up to three 64 bits pointer in it. Isn't it 
enough?

-- 
Benoit Minisini



From ron at ...572...  Fri Jan 18 08:48:14 2008
From: ron at ...572... (Ron)
Date: Fri, 18 Jan 2008 08:48:14 +0100
Subject: [Gambas-devel] 64bit autoconf requirement
In-Reply-To: <200801172000.43602.gambas@...1...>
References: <478A5524.5060402@...572...>
	<200801172000.43602.gambas@...1...>
Message-ID: <479059BE.2090502@...572...>

Benoit Minisini schreef:
> On dimanche 13 janvier 2008, Ron wrote:
>   
>> Hi Benoit,
>>
>> The 64bits gambas  trunk uses a different autoconf as the 32bits version
>> does.
>> It needs 2.61 to support the no-recursive flag, CentOS 5.1 and RedHat
>> RHEL5 still have 2.59-12, this means gambas cannot be compiled on those
>> platforms
>> without installing an unsupported package.
>>
>> Otherwise you get this error while running ./reconf
>> /usr/bin/autoreconf: unrecognized option `--no-recursive'
>>     
>
> I removed the use of this option.
>
>   
>> I have:
>> [root at ...573... 64bits]# yum list installed|grep autoconf
>> autoconf.noarch                          2.59-12
>> installed
>>
>> I then compiled and installed autoconf 2.61 manually to be able to
>> provide you with debug info for gambas 64 bits.
>> Would be nice if the final release uses the old autoconf again to
>> prevent compilation problems (if possible)
>>     
>
> What prevents you from upgrading your OS?
>
>   

Strangely enough my OS is uptodate CentOS 5.1 is the latest with all 
updates, I have no idea why they stick to the old version of autoconf.

I'm going to move to Fedora Core 8 64bits, more suited for Desktop use.

>> My ./configure run keeps failing with:
>> ------- cut ---------
>> ...
>> ...
>> === configuring in gb.sdl (/home/ron/build/gambas/64bits/gb.sdl)
>> configure: running /bin/sh ./configure '--prefix=/usr/local'
>> --cache-file=/dev/null --srcdir=.
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking build system type... x86_64-unknown-linux-gnu
>> checking for style of include used by make... GNU
>> checking whether to enable maintainer-specific portions of Makefiles... no
>> checking host system type... x86_64-unknown-linux-gnu
>> checking for gcc... gcc
>> checking for C compiler default output file name... a.out
>> checking whether the C compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables...
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking dependency style of gcc... gcc3
>> checking how to run the C preprocessor... gcc -E
>> checking for g++... no
>> checking for c++... no
>> checking for gpp... no
>> checking for aCC... no
>> checking for CC... no
>> checking for cxx... no
>> checking for cc++... no
>> checking for cl.exe... no
>> checking for FCC... no
>> checking for KCC... no
>> checking for RCC... no
>> checking for xlC_r... no
>> checking for xlC... no
>> checking whether we are using the GNU C++ compiler... no
>> checking whether g++ accepts -g... no
>> checking dependency style of g++... none
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether ln -s works... yes
>> checking whether make sets $(MAKE)... (cached) yes
>> checking for setenv... yes
>> checking for unsetenv... yes
>> checking for getdomainname... yes
>> checking for getpt... yes
>> checking for ccache... no
>> checking for main in -lm... yes
>> checking for main in -lz... yes
>> checking for main in -lgcc_s... yes
>> checking for main in -lstdc++... no
>> checking target system... LINUX
>> checking which extension is used for shared libraries... .so
>> checking for threading compiler options... -D_REENTRANT
>> checking for threading linker options... -lpthread
>> checking for mathematic libraries... -lm
>> checking CFLAGS for gcc -fvisibility=hidden... -fvisibility=hidden
>> checking for a sed that does not truncate output... /bin/sed
>> checking for grep that handles long lines and -e... /bin/grep
>> checking for egrep... /bin/grep -E
>> checking for ld used by gcc... /usr/bin/ld
>> checking if the linker (/usr/bin/ld) is GNU ld... yes
>> checking for /usr/bin/ld option to reload object files... -r
>> checking for BSD-compatible nm... /usr/bin/nm -B
>> checking how to recognize dependent libraries... pass_all
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking dlfcn.h usability... yes
>> checking dlfcn.h presence... yes
>> checking for dlfcn.h... yes
>> checking for g77... no
>> checking for xlf... no
>> checking for f77... no
>> checking for frt... no
>> checking for pgf77... no
>> checking for cf77... no
>> checking for fort77... no
>> checking for fl32... no
>> checking for af77... no
>> checking for xlf90... no
>> checking for f90... no
>> checking for pgf90... no
>> checking for pghpf... no
>> checking for epcf90... no
>> checking for gfortran... no
>> checking for g95... no
>> checking for xlf95... no
>> checking for f95... no
>> checking for fort... no
>> checking for ifort... no
>> checking for ifc... no
>> checking for efc... no
>> checking for pgf95... no
>> checking for lf95... no
>> checking for ftn... no
>> checking whether we are using the GNU Fortran 77 compiler... no
>> checking whether  accepts -g... no
>> checking the maximum length of command line arguments... 98304
>> checking command to parse /usr/bin/nm -B output from gcc object... ok
>> checking for objdir... .libs
>> checking for ar... ar
>> checking for ranlib... ranlib
>> checking for strip... strip
>> checking if gcc supports -fno-rtti -fno-exceptions... no
>> checking for gcc option to produce PIC... -fPIC
>> checking if gcc PIC flag -fPIC works... yes
>> checking if gcc static flag -static works... yes
>> checking if gcc supports -c -o file.o... yes
>> checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports
>> shared libraries... yes
>> checking whether -lc should be explicitly linked in... no
>> checking dynamic linker characteristics... GNU/Linux ld.so
>> checking how to hardcode library paths into programs... immediate
>> checking whether stripping libraries is possible... yes
>> checking for shl_load... no
>> checking for shl_load in -ldld... no
>> checking for dlopen... no
>> checking for dlopen in -ldl... yes
>> checking whether a program can dlopen itself... yes
>> checking whether a statically linked program can dlopen itself... no
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... no
>> configure: creating libtool
>> appending configuration tag "CXX" to libtool
>> appending configuration tag "F77" to libtool
>> checking for X... libraries /usr/lib64, headers
>> checking whether -R must be followed by a space... neither works
>> checking for gethostbyname... yes
>> checking for connect... yes
>> checking for remove... yes
>> checking for shmat... yes
>> checking for IceConnectionNumber in -lICE... yes
>> ./configure: line 21896: syntax error near unexpected token `1.2.8,'
>> ./configure: line 21896: `GB_PATH_SDL(1.2.8, , touch DISABLED)'
>> configure: error: ./configure failed for gb.sdl
>> ---------- cut -------------
>>
>> Any idea? Or local problem...
>>     
>
> Not really, maybe Laurent. Did you install all needed SDL development 
> packages?
>
>   
I'm unsure of all the requirements where met, but if not, configure 
should only say ' Not installing....sdl component'
Now it seems as if it detected it 50%.

If I remove this line the compile goes on:

./configure: line 21896: `GB_PATH_SDL(1.2.8, , touch DISABLED)'

But, like I said, i'm installing another more desktop aware OS this weekend.

Regards,
Ron.
> Regards,
>
>   




From dcamposf at ...176...  Fri Jan 18 11:44:30 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Fri, 18 Jan 2008 11:44:30 +0100
Subject: [Gambas-devel] 64 bits branch merge
In-Reply-To: <200801180046.03060.gambas@...1...>
References: <200801172237.05659.gambas@...1...>
	<200801172245.20495.gambas@...1...>
	<7259b5ae0801171536q65b6c902j14fab0a91aaef0ad@...178...>
	<200801180046.03060.gambas@...1...>
Message-ID: <7259b5ae0801180244k30574638t71a55eea8f356205@...178...>

>
> At the moment, you can store up to three 64 bits pointer in it. Isn't it
> enough?
>

Yes, I can do it with the current GB_STREAM definition, but let's say
that my old code was not optimized :-). I do not need a bigger
structure, just to redesign it a bit



From gambas at ...1...  Fri Jan 18 12:40:00 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 18 Jan 2008 12:40:00 +0100
Subject: [Gambas-devel] 64 bits branch merge done
Message-ID: <200801181240.00880.gambas@...1...>

Hi,

The merge has been done. We went back to:

* /trunk, that is the next 3.0 version.

* /branches/2.0, that is the next 2.1 version.

So, from now, if you have to do your 64 bits fixes both in /trunk and 
in /branches/2.0.

Everyone is invited to test the /branches/2.0 on their 64 bits and 32 bits 
system (because 64 bits changes can break the old code), and report any 
problem!

Regards,

-- 
Benoit Minisini



From jredrejo at ...176...  Fri Jan 18 13:17:03 2008
From: jredrejo at ...176... (=?ISO-8859-1?Q?Jos=E9_Luis_Redrejo?=)
Date: Fri, 18 Jan 2008 13:17:03 +0100
Subject: [Gambas-devel] 64 bits branch merge done
In-Reply-To: <200801181240.00880.gambas@...1...>
References: <200801181240.00880.gambas@...1...>
Message-ID: <8eb28a500801180417v30b13516n7a50738923b395af@...178...>

2008/1/18, Benoit Minisini <gambas at ...1...>:
>
> Hi,
>
> The merge has been done. We went back to:
>
> * /trunk, that is the next 3.0 version.
>
> * /branches/2.0, that is the next 2.1 version.
>
> So, from now, if you have to do your 64 bits fixes both in /trunk and
> in /branches/2.0.
>
> Everyone is invited to test the /branches/2.0 on their 64 bits and 32 bits
> system (because 64 bits changes can break the old code), and report any
> problem!
>
> Regards,
>
>
Beno?t, do you think it makes sense prepare new packages for the  new merge
and allow Debian machines build the code in all the architectures? If I do
it and it fails, reversing to i386 only will take some protocols and time,
but doing it will let more users test it in different archs.
Also, in the past I checked there were problems compiling gambas 1.0 in
powerpc because of endianess isues, do you think this issues might have been
fixed with the modifications for 64 bits?.
And latest, but not least, if you think that packaging the merged version is
a good idea, maybe you should officially release it as 2.0.1 or similar and
more distros will do the same...

Regards.
Jos? L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080118/72437afb/attachment.html>

From gambas at ...1...  Fri Jan 18 13:35:11 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 18 Jan 2008 13:35:11 +0100
Subject: [Gambas-devel] 64 bits branch merge done
In-Reply-To: <8eb28a500801180417v30b13516n7a50738923b395af@...178...>
References: <200801181240.00880.gambas@...1...>
	<8eb28a500801180417v30b13516n7a50738923b395af@...178...>
Message-ID: <200801181335.11710.gambas@...1...>

On vendredi 18 janvier 2008, Jos? Luis Redrejo wrote:
> 2008/1/18, Benoit Minisini <gambas at ...1...>:
> > Hi,
> >
> > The merge has been done. We went back to:
> >
> > * /trunk, that is the next 3.0 version.
> >
> > * /branches/2.0, that is the next 2.1 version.
> >
> > So, from now, if you have to do your 64 bits fixes both in /trunk and
> > in /branches/2.0.
> >
> > Everyone is invited to test the /branches/2.0 on their 64 bits and 32
> > bits system (because 64 bits changes can break the old code), and report
> > any problem!
> >
> > Regards,
>
> Beno?t, do you think it makes sense prepare new packages for the  new merge
> and allow Debian machines build the code in all the architectures? If I do
> it and it fails, reversing to i386 only will take some protocols and time,
> but doing it will let more users test it in different archs.
> Also, in the past I checked there were problems compiling gambas 1.0 in
> powerpc because of endianess isues, do you think this issues might have
> been fixed with the modifications for 64 bits?.
> And latest, but not least, if you think that packaging the merged version
> is a good idea, maybe you should officially release it as 2.0.1 or similar
> and more distros will do the same...
>
> Regards.
> Jos? L.

I'd like a few user testing all the examples, the IDE and the database manager 
before releasing the version (2.1, not 2.0.1). I can't do these tests myself 
at the moment.

As for the endianess issues, the 64 bits port won't change them, this is an 
orthogonal problem. 

But it is just a matter of giving me a full ssh access to a big-endian OS so 
that I can debug. Rob Kudla did that with its 64 bits Ubuntu system, and it 
speeded up things.

Regards,

-- 
Benoit Minisini



From dcamposf at ...176...  Fri Jan 18 16:00:30 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Fri, 18 Jan 2008 16:00:30 +0100
Subject: [Gambas-devel] 64 bits branch merge done
In-Reply-To: <200801181335.11710.gambas@...1...>
References: <200801181240.00880.gambas@...1...>
	<8eb28a500801180417v30b13516n7a50738923b395af@...178...>
	<200801181335.11710.gambas@...1...>
Message-ID: <7259b5ae0801180700x6d6cbd5enc7e4930f7489bfd9@...178...>

Hi Benoit:

Now that you're using a backend for external calls, could you
consideer adding support for C structures handling? I had this feature
in my old gb.api component from which you extracted the original API
code, and now with gambas alone It's difficult to manage external
calls when you have to fill or read values from structures passed to
functions, i think this could be quite interesting for many people -
or If you have documentation about that backend and you want the
structure support in an external component, I can do that, and I would
like add support for callbacks too, which are quite used in libraries.

So far I found not information about libffi in Google... :-(

Daniel


2008/1/18, Benoit Minisini <gambas at ...1...>:
> On vendredi 18 janvier 2008, Jos? Luis Redrejo wrote:
> > 2008/1/18, Benoit Minisini <gambas at ...1...>:
> > > Hi,
> > >
> > > The merge has been done. We went back to:
> > >
> > > * /trunk, that is the next 3.0 version.
> > >
> > > * /branches/2.0, that is the next 2.1 version.
> > >
> > > So, from now, if you have to do your 64 bits fixes both in /trunk and
> > > in /branches/2.0.
> > >
> > > Everyone is invited to test the /branches/2.0 on their 64 bits and 32
> > > bits system (because 64 bits changes can break the old code), and report
> > > any problem!
> > >
> > > Regards,
> >
> > Beno?t, do you think it makes sense prepare new packages for the  new merge
> > and allow Debian machines build the code in all the architectures? If I do
> > it and it fails, reversing to i386 only will take some protocols and time,
> > but doing it will let more users test it in different archs.
> > Also, in the past I checked there were problems compiling gambas 1.0 in
> > powerpc because of endianess isues, do you think this issues might have
> > been fixed with the modifications for 64 bits?.
> > And latest, but not least, if you think that packaging the merged version
> > is a good idea, maybe you should officially release it as 2.0.1 or similar
> > and more distros will do the same...
> >
> > Regards.
> > Jos? L.
>
> I'd like a few user testing all the examples, the IDE and the database manager
> before releasing the version (2.1, not 2.0.1). I can't do these tests myself
> at the moment.
>
> As for the endianess issues, the 64 bits port won't change them, this is an
> orthogonal problem.
>
> But it is just a matter of giving me a full ssh access to a big-endian OS so
> that I can debug. Rob Kudla did that with its 64 bits Ubuntu system, and it
> speeded up things.
>
> Regards,
>
> --
> Benoit Minisini
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>



From gambas at ...1...  Fri Jan 18 16:57:50 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 18 Jan 2008 16:57:50 +0100
Subject: [Gambas-devel] 64 bits branch merge done
In-Reply-To: <7259b5ae0801180700x6d6cbd5enc7e4930f7489bfd9@...178...>
References: <200801181240.00880.gambas@...1...>
	<200801181335.11710.gambas@...1...>
	<7259b5ae0801180700x6d6cbd5enc7e4930f7489bfd9@...178...>
Message-ID: <200801181657.50387.gambas@...1...>

On vendredi 18 janvier 2008, Daniel Campos wrote:
> Hi Benoit:
>
> Now that you're using a backend for external calls, could you
> consideer adding support for C structures handling? I had this feature
> in my old gb.api component from which you extracted the original API
> code, and now with gambas alone It's difficult to manage external
> calls when you have to fill or read values from structures passed to
> functions, i think this could be quite interesting for many people -
> or If you have documentation about that backend and you want the
> structure support in an external component, I can do that, and I would
> like add support for callbacks too, which are quite used in libraries.
>
> So far I found not information about libffi in Google... :-(
>
> Daniel
>

If you type "libffi" in google, the first answer is the project home site. 
There is no documentation about libffi, you must look into a sparse README 
file and into the source code.

But the problem is not libffi, but Gambas there! I don't know yet how to make 
support for structures and callbacks, but I will think about it. It will need 
a lot of work.

Regards,

-- 
Benoit Minisini



From scatman at ...571...  Fri Jan 18 22:43:27 2008
From: scatman at ...571... (scatman)
Date: Fri, 18 Jan 2008 22:43:27 +0100
Subject: [Gambas-devel] font probs
Message-ID: <200801182243.28058.scatman@...571...>

Revision 1011

picture says more as any words :)

UTF-8 @ X11 here.

Warning: Use the 64 bits version of Gambas at your own risk!
Fontconfig warning: no <cachedir> elements found. Check configuration.
Fontconfig warning: adding <cachedir>/var/cache/fontconfig</cachedir>
Fontconfig warning: adding <cachedir>~/.fontconfig</cachedir>

please look in attachment...

thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambas_trunk.jpeg
Type: image/jpeg
Size: 99073 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080118/e0419a2b/attachment.jpeg>

From dcamposf at ...176...  Fri Jan 18 22:53:31 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Fri, 18 Jan 2008 22:53:31 +0100
Subject: [Gambas-devel] 64 bits branch merge done
In-Reply-To: <200801181657.50387.gambas@...1...>
References: <200801181240.00880.gambas@...1...>
	<200801181335.11710.gambas@...1...>
	<7259b5ae0801180700x6d6cbd5enc7e4930f7489bfd9@...178...>
	<200801181657.50387.gambas@...1...>
Message-ID: <7259b5ae0801181353hcf1b70ao9cfc951dbef89384@...178...>

>
> If you type "libffi" in google, the first answer is the project home site.
> There is no documentation about libffi, you must look into a sparse README
> file and into the source code.
>
> But the problem is not libffi, but Gambas there! I don't know yet how to make
> support for structures and callbacks, but I will think about it. It will need
> a lot of work.
>

I already did that work for 32 bits systems, I can explore the way to
do it in 64 bits if you want, btw, Is there in gcc any definition I
can use to determine a 64 bits compilation?

Daniel



From gambas at ...1...  Fri Jan 18 23:05:34 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 18 Jan 2008 23:05:34 +0100
Subject: [Gambas-devel] font probs
In-Reply-To: <200801182243.28058.scatman@...571...>
References: <200801182243.28058.scatman@...571...>
Message-ID: <200801182305.34693.gambas@...1...>

On vendredi 18 janvier 2008, scatman wrote:
> Revision 1011
>
> picture says more as any words :)
>
> UTF-8 @ X11 here.
>
> Warning: Use the 64 bits version of Gambas at your own risk!
> Fontconfig warning: no <cachedir> elements found. Check configuration.
> Fontconfig warning: adding <cachedir>/var/cache/fontconfig</cachedir>
> Fontconfig warning: adding <cachedir>~/.fontconfig</cachedir>

These messages tell you that you have a problem in the font configuration of 
your (unknown) system.

Regards,

-- 
Benoit Minisini



From gambas at ...1...  Fri Jan 18 23:14:34 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 18 Jan 2008 23:14:34 +0100
Subject: [Gambas-devel] 64 bits branch merge done
In-Reply-To: <7259b5ae0801181353hcf1b70ao9cfc951dbef89384@...178...>
References: <200801181240.00880.gambas@...1...>
	<200801181657.50387.gambas@...1...>
	<7259b5ae0801181353hcf1b70ao9cfc951dbef89384@...178...>
Message-ID: <200801182314.34219.gambas@...1...>

On vendredi 18 janvier 2008, Daniel Campos wrote:
> > If you type "libffi" in google, the first answer is the project home
> > site. There is no documentation about libffi, you must look into a sparse
> > README file and into the source code.
> >
> > But the problem is not libffi, but Gambas there! I don't know yet how to
> > make support for structures and callbacks, but I will think about it. It
> > will need a lot of work.
>
> I already did that work for 32 bits systems, I can explore the way to
> do it in 64 bits if you want, btw, Is there in gcc any definition I
> can use to determine a 64 bits compilation?
>
> Daniel
>

As for structure support, this needs big changes in the compiler, in the 
interpreter, in the object file format, and maybe in the bytecode. There is 
support for C-like structures in libffi, so passing them to a function will 
not be a problem.

As for callback support, I have no idea how you could do that correctly.

Note that libffi uses assembly for calling functions, so that it can deal with 
the different ABI of 64 bits systems and 32 bits systems (Hopefully, there is 
only one ABI for 64 bits systems, but several for 32 bits systems). 

And there is no support for callbacks in libffi. So please explain me how you 
implemented them, without using assembly! :-)

Regards,

-- 
Benoit Minisini



From gambas at ...1...  Fri Jan 18 23:37:08 2008
From: gambas at ...1... (Benoit Minisini)
Date: Fri, 18 Jan 2008 23:37:08 +0100
Subject: [Gambas-devel] 64 bits branch merge done
In-Reply-To: <200801182314.34219.gambas@...1...>
References: <200801181240.00880.gambas@...1...>
	<7259b5ae0801181353hcf1b70ao9cfc951dbef89384@...178...>
	<200801182314.34219.gambas@...1...>
Message-ID: <200801182337.08667.gambas@...1...>

On vendredi 18 janvier 2008, Benoit Minisini wrote:
> On vendredi 18 janvier 2008, Daniel Campos wrote:
> > > If you type "libffi" in google, the first answer is the project home
> > > site. There is no documentation about libffi, you must look into a
> > > sparse README file and into the source code.
> > >
> > > But the problem is not libffi, but Gambas there! I don't know yet how
> > > to make support for structures and callbacks, but I will think about
> > > it. It will need a lot of work.
> >
> > I already did that work for 32 bits systems, I can explore the way to
> > do it in 64 bits if you want, btw, Is there in gcc any definition I
> > can use to determine a 64 bits compilation?
> >
> > Daniel
>
> As for structure support, this needs big changes in the compiler, in the
> interpreter, in the object file format, and maybe in the bytecode. There is
> support for C-like structures in libffi, so passing them to a function will
> not be a problem.
>
> As for callback support, I have no idea how you could do that correctly.
>
> Note that libffi uses assembly for calling functions, so that it can deal
> with the different ABI of 64 bits systems and 32 bits systems (Hopefully,
> there is only one ABI for 64 bits systems, but several for 32 bits
> systems).
>
> And there is no support for callbacks in libffi. So please explain me how
> you implemented them, without using assembly! :-)
>
> Regards,

I was wrong. Apparently, there is some support for callbacks in libffi 
(named 'closures'), but I didn't find any documentation about it. Maybe by 
using the code search of Google...

-- 
Benoit Minisini



From scatman at ...571...  Sat Jan 19 00:23:13 2008
From: scatman at ...571... (scatman)
Date: Sat, 19 Jan 2008 00:23:13 +0100
Subject: [Gambas-devel] font probs
In-Reply-To: <200801182305.34693.gambas@...1...>
References: <200801182243.28058.scatman@...571...>
	<200801182305.34693.gambas@...1...>
	(sfid-20080118_231056_221788_CB9F0222EAA14D8)
Message-ID: <200801190023.13610.scatman@...571...>

Am Freitag, 18. Januar 2008 schrieb Benoit Minisini:
> On vendredi 18 janvier 2008, scatman wrote:
> > Revision 1011
> >
> > picture says more as any words :)
> >
> > UTF-8 @ X11 here.
> >
> > Warning: Use the 64 bits version of Gambas at your own risk!
> > Fontconfig warning: no <cachedir> elements found. Check configuration.
> > Fontconfig warning: adding <cachedir>/var/cache/fontconfig</cachedir>
> > Fontconfig warning: adding <cachedir>~/.fontconfig</cachedir>
>
> These messages tell you that you have a problem in the font configuration
> of your (unknown) system.

hmm, befor 1011 i have no probs with gambas and the fonts on gentoo.






From gambas at ...1...  Sat Jan 19 00:28:46 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sat, 19 Jan 2008 00:28:46 +0100
Subject: [Gambas-devel] font probs
In-Reply-To: <200801190023.13610.scatman@...571...>
References: <200801182243.28058.scatman@...571...>
	<200801182305.34693.gambas@...1...>
	<200801190023.13610.scatman@...571...>
Message-ID: <200801190028.46816.gambas@...1...>

On samedi 19 janvier 2008, scatman wrote:
> Am Freitag, 18. Januar 2008 schrieb Benoit Minisini:
> > On vendredi 18 janvier 2008, scatman wrote:
> > > Revision 1011
> > >
> > > picture says more as any words :)
> > >
> > > UTF-8 @ X11 here.
> > >
> > > Warning: Use the 64 bits version of Gambas at your own risk!
> > > Fontconfig warning: no <cachedir> elements found. Check configuration.
> > > Fontconfig warning: adding <cachedir>/var/cache/fontconfig</cachedir>
> > > Fontconfig warning: adding <cachedir>~/.fontconfig</cachedir>
> >
> > These messages tell you that you have a problem in the font configuration
> > of your (unknown) system.
>
> hmm, befor 1011 i have no probs with gambas and the fonts on gentoo.
>

Try to change the gui component used by your project to see if these messages 
depends on the toolkit. 

Try with a different user account too.

-- 
Benoit Minisini



From scatman at ...571...  Sat Jan 19 12:17:30 2008
From: scatman at ...571... (scatman)
Date: Sat, 19 Jan 2008 12:17:30 +0100
Subject: [Gambas-devel] font probs
In-Reply-To: <200801190028.46816.gambas@...1...>
References: <200801182243.28058.scatman@...571...>
	<200801190023.13610.scatman@...571...>
	<200801190028.46816.gambas@...1...>
	(sfid-20080119_085245_170772_85FF4925BD486F1C)
Message-ID: <200801191217.30785.scatman@...571...>

Am Samstag, 19. Januar 2008 schrieb Benoit Minisini:

Hello,

>
> Try to change the gui component used by your project to see if these
> messages depends on the toolkit.
same result.

> Try with a different user account too.
same result.

Hmm, it is a Problem with fontconfig, but i have no idea what?s going wrong.
If i rename or move /etc/fonts/fonts.conf gambas says
Fontconfig error: Cannot load default config file. logical

but gambas started and allready ist fine with fonts ;)





From dcamposf at ...176...  Sun Jan 20 15:58:18 2008
From: dcamposf at ...176... (Daniel Campos)
Date: Sun, 20 Jan 2008 15:58:18 +0100
Subject: [Gambas-devel] 64 bits branch merge done
In-Reply-To: <200801182337.08667.gambas@...1...>
References: <200801181240.00880.gambas@...1...>
	<7259b5ae0801181353hcf1b70ao9cfc951dbef89384@...178...>
	<200801182314.34219.gambas@...1...>
	<200801182337.08667.gambas@...1...>
Message-ID: <7259b5ae0801200658i629d0b1djdc401fc77c01ddbf@...178...>

I was trying to get the old gb.api code from the server it is stored,
but it seems the server is down, I hope I'll can rescue it this week.
Anyway I'll take a look at libffi, I did without documentation for
poppler :-), so I suppose I'll be able to implement both structures
and callbacks with libffi provided that it supports those features :-)

2008/1/18, Benoit Minisini <gambas at ...1...>:
> On vendredi 18 janvier 2008, Benoit Minisini wrote:
> > On vendredi 18 janvier 2008, Daniel Campos wrote:
> > > > If you type "libffi" in google, the first answer is the project home
> > > > site. There is no documentation about libffi, you must look into a
> > > > sparse README file and into the source code.
> > > >
> > > > But the problem is not libffi, but Gambas there! I don't know yet how
> > > > to make support for structures and callbacks, but I will think about
> > > > it. It will need a lot of work.
> > >
> > > I already did that work for 32 bits systems, I can explore the way to
> > > do it in 64 bits if you want, btw, Is there in gcc any definition I
> > > can use to determine a 64 bits compilation?
> > >
> > > Daniel
> >
> > As for structure support, this needs big changes in the compiler, in the
> > interpreter, in the object file format, and maybe in the bytecode. There is
> > support for C-like structures in libffi, so passing them to a function will
> > not be a problem.
> >
> > As for callback support, I have no idea how you could do that correctly.
> >
> > Note that libffi uses assembly for calling functions, so that it can deal
> > with the different ABI of 64 bits systems and 32 bits systems (Hopefully,
> > there is only one ABI for 64 bits systems, but several for 32 bits
> > systems).
> >
> > And there is no support for callbacks in libffi. So please explain me how
> > you implemented them, without using assembly! :-)
> >
> > Regards,
>
> I was wrong. Apparently, there is some support for callbacks in libffi
> (named 'closures'), but I didn't find any documentation about it. Maybe by
> using the code search of Google...
>
> --
> Benoit Minisini
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>



From ron at ...572...  Thu Jan 24 16:19:35 2008
From: ron at ...572... (Ron)
Date: Thu, 24 Jan 2008 16:19:35 +0100
Subject: [Gambas-devel] configure failed
In-Reply-To: <200801171716.10304.scatman@...571...>
References: <200801171716.10304.scatman@...571...>
Message-ID: <4798AC87.2020901@...572...>

scatman schreef:
> Hello,
>
> rev 1000 and 1002.
> gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)
>
> the haeder files from libffi are stored in Gentoo under /usr/include/libffi. 
> The configure Script only looking in /usr/include for ffi.h and  
> ffitarget.h and configure failed. Ok, no Problem. I make Symlinks 
> to /usr/include and start configure again. ffi.h and ffitarget.h are found 
> and configure finished. 
> But make gives me now this error.
>
> ########################################################
>
> array.o gbx3-gbx_c_process.o gbx3-gbx_c_subcollection.o gbx3-gbx_c_string.o 
> gbx3-gbx_component.o gbx3-gbx_extern.o gbx3-gbx_print.o gbx3-gbx_c_enum.o 
> gbx3-gbx_c_timer.o gbx3-gbx_c_quote.o  -lm -ldl
> gbx3-gbx_extern.o: In function `EXTERN_call':
> /home/test/64bits/main/gbx/gbx_extern.c:338: undefined reference to 
> `ffi_prep_cif'
> /home/test/64bits/main/gbx/gbx_extern.c:341: undefined reference to 
> `ffi_call'
> gbx3-gbx_extern.o:(.rodata+0x50): undefined reference to `ffi_type_void'
> gbx3-gbx_extern.o:(.rodata+0x58): undefined reference to `ffi_type_sint32'
> gbx3-gbx_extern.o:(.rodata+0x60): undefined reference to `ffi_type_sint32'
> gbx3-gbx_extern.o:(.rodata+0x68): undefined reference to `ffi_type_sint32'
> gbx3-gbx_extern.o:(.rodata+0x70): undefined reference to `ffi_type_sint32'
> gbx3-gbx_extern.o:(.rodata+0x78): undefined reference to `ffi_type_sint64'
> gbx3-gbx_extern.o:(.rodata+0x80): undefined reference to `ffi_type_float'
> gbx3-gbx_extern.o:(.rodata+0x88): undefined reference to `ffi_type_double'
> gbx3-gbx_extern.o:(.rodata+0x90): undefined reference to `ffi_type_void'
> gbx3-gbx_extern.o:(.rodata+0x98): undefined reference to `ffi_type_pointer'
> gbx3-gbx_extern.o:(.rodata+0xa0): undefined reference to `ffi_type_pointer'
> gbx3-gbx_extern.o:(.rodata+0xa8): undefined reference to `ffi_type_void'
> gbx3-gbx_extern.o:(.rodata+0xb0): undefined reference to `ffi_type_void'
> gbx3-gbx_extern.o:(.rodata+0xb8): undefined reference to `ffi_type_void'
> gbx3-gbx_extern.o:(.rodata+0xc0): undefined reference to `ffi_type_void'
> gbx3-gbx_extern.o:(.rodata+0xc8): undefined reference to `ffi_type_pointer'
> gbx3-gbx_extern.o:(.rodata+0xd0): undefined reference to `ffi_type_pointer'
> collect2: ld returned 1 exit status
> make[4]: *** [gbx3] Error 1
>
> Thanks
>
>   
Hi,

I'm on CentOS 5.1 x86_64 again, and have build an rpm for libffi which 
installs these files:
(sources are from sources.redhat.com:/cvs/libffi )

/usr/lib64/libffi.la
/usr/lib64/libffi.so
/usr/lib64/libffi.so.4
/usr/lib64/libffi.a
/usr/lib64/libffi.so.4.0.1
/usr/include/ffi.h
/usr/include/ffitarget.h

# ldconfig -v|grep ffi
/usr/lib64
        libffi.so.4 -> libffi.so.4.0.1

The ffi .h files are found correctly by gambas make, but the errors 
above (which I had too), are due to the configure/make process not 
linking the libffi to gbx2
When I tweak the main/gbx/Makefile by adding -lffi on this line:

gbx2_LDADD = -lm    -ldl   -lffi

the compile of gbx2 succeeds!...

Which info/output do I have to sent, so you guys can fix the 
configure/make files, and I don't have to hack the Makefile manually?

CentOS 5.1
gambas 2.0 from cvs today
gcc version 4.1.2

Thanks,
Ron.




From gambas at ...1...  Thu Jan 24 16:28:08 2008
From: gambas at ...1... (Benoit Minisini)
Date: Thu, 24 Jan 2008 16:28:08 +0100
Subject: [Gambas-devel] configure failed
In-Reply-To: <4798AC87.2020901@...572...>
References: <200801171716.10304.scatman@...571...>
	<4798AC87.2020901@...572...>
Message-ID: <200801241628.08642.gambas@...1...>

On jeudi 24 janvier 2008, Ron wrote:
> scatman schreef:
> > Hello,
> >
> > rev 1000 and 1002.
> > gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)
> >
> > the haeder files from libffi are stored in Gentoo under
> > /usr/include/libffi. The configure Script only looking in /usr/include
> > for ffi.h and
> > ffitarget.h and configure failed. Ok, no Problem. I make Symlinks
> > to /usr/include and start configure again. ffi.h and ffitarget.h are
> > found and configure finished.
> > But make gives me now this error.
> >
> > ########################################################
> >
> > array.o gbx3-gbx_c_process.o gbx3-gbx_c_subcollection.o
> > gbx3-gbx_c_string.o gbx3-gbx_component.o gbx3-gbx_extern.o
> > gbx3-gbx_print.o gbx3-gbx_c_enum.o gbx3-gbx_c_timer.o gbx3-gbx_c_quote.o 
> > -lm -ldl
> > gbx3-gbx_extern.o: In function `EXTERN_call':
> > /home/test/64bits/main/gbx/gbx_extern.c:338: undefined reference to
> > `ffi_prep_cif'
> > /home/test/64bits/main/gbx/gbx_extern.c:341: undefined reference to
> > `ffi_call'
> > gbx3-gbx_extern.o:(.rodata+0x50): undefined reference to `ffi_type_void'
> > gbx3-gbx_extern.o:(.rodata+0x58): undefined reference to
> > `ffi_type_sint32' gbx3-gbx_extern.o:(.rodata+0x60): undefined reference
> > to `ffi_type_sint32' gbx3-gbx_extern.o:(.rodata+0x68): undefined
> > reference to `ffi_type_sint32' gbx3-gbx_extern.o:(.rodata+0x70):
> > undefined reference to `ffi_type_sint32'
> > gbx3-gbx_extern.o:(.rodata+0x78): undefined reference to
> > `ffi_type_sint64' gbx3-gbx_extern.o:(.rodata+0x80): undefined reference
> > to `ffi_type_float' gbx3-gbx_extern.o:(.rodata+0x88): undefined reference
> > to `ffi_type_double' gbx3-gbx_extern.o:(.rodata+0x90): undefined
> > reference to `ffi_type_void' gbx3-gbx_extern.o:(.rodata+0x98): undefined
> > reference to `ffi_type_pointer' gbx3-gbx_extern.o:(.rodata+0xa0):
> > undefined reference to `ffi_type_pointer'
> > gbx3-gbx_extern.o:(.rodata+0xa8): undefined reference to `ffi_type_void'
> > gbx3-gbx_extern.o:(.rodata+0xb0): undefined reference to `ffi_type_void'
> > gbx3-gbx_extern.o:(.rodata+0xb8): undefined reference to `ffi_type_void'
> > gbx3-gbx_extern.o:(.rodata+0xc0): undefined reference to `ffi_type_void'
> > gbx3-gbx_extern.o:(.rodata+0xc8): undefined reference to
> > `ffi_type_pointer' gbx3-gbx_extern.o:(.rodata+0xd0): undefined reference
> > to `ffi_type_pointer' collect2: ld returned 1 exit status
> > make[4]: *** [gbx3] Error 1
> >
> > Thanks
>
> Hi,
>
> I'm on CentOS 5.1 x86_64 again, and have build an rpm for libffi which
> installs these files:
> (sources are from sources.redhat.com:/cvs/libffi )
>
> /usr/lib64/libffi.la
> /usr/lib64/libffi.so
> /usr/lib64/libffi.so.4
> /usr/lib64/libffi.a
> /usr/lib64/libffi.so.4.0.1
> /usr/include/ffi.h
> /usr/include/ffitarget.h
>
> # ldconfig -v|grep ffi
> /usr/lib64
>         libffi.so.4 -> libffi.so.4.0.1
>
> The ffi .h files are found correctly by gambas make, but the errors
> above (which I had too), are due to the configure/make process not
> linking the libffi to gbx2
> When I tweak the main/gbx/Makefile by adding -lffi on this line:
>
> gbx2_LDADD = -lm    -ldl   -lffi
>
> the compile of gbx2 succeeds!...
>
> Which info/output do I have to sent, so you guys can fix the
> configure/make files, and I don't have to hack the Makefile manually?
>
> CentOS 5.1
> gambas 2.0 from cvs today
> gcc version 4.1.2
>
> Thanks,
> Ron.
>
>

Did you ./reconf everything after having installed libffi?

-- 
Benoit Minisini



From ron at ...572...  Thu Jan 24 16:44:55 2008
From: ron at ...572... (Ron)
Date: Thu, 24 Jan 2008 16:44:55 +0100
Subject: [Gambas-devel] configure failed
In-Reply-To: <200801241628.08642.gambas@...1...>
References: <200801171716.10304.scatman@...571...>	<4798AC87.2020901@...572...>
	<200801241628.08642.gambas@...1...>
Message-ID: <4798B277.1030206@...572...>

Benoit Minisini schreef:
> On jeudi 24 janvier 2008, Ron wrote:
>   
>> scatman schreef:
>>     
>>> Hello,
>>>
>>> rev 1000 and 1002.
>>> gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)
>>>
>>> the haeder files from libffi are stored in Gentoo under
>>> /usr/include/libffi. The configure Script only looking in /usr/include
>>> for ffi.h and
>>> ffitarget.h and configure failed. Ok, no Problem. I make Symlinks
>>> to /usr/include and start configure again. ffi.h and ffitarget.h are
>>> found and configure finished.
>>> But make gives me now this error.
>>>
>>> ########################################################
>>>
>>> array.o gbx3-gbx_c_process.o gbx3-gbx_c_subcollection.o
>>> gbx3-gbx_c_string.o gbx3-gbx_component.o gbx3-gbx_extern.o
>>> gbx3-gbx_print.o gbx3-gbx_c_enum.o gbx3-gbx_c_timer.o gbx3-gbx_c_quote.o 
>>> -lm -ldl
>>> gbx3-gbx_extern.o: In function `EXTERN_call':
>>> /home/test/64bits/main/gbx/gbx_extern.c:338: undefined reference to
>>> `ffi_prep_cif'
>>> /home/test/64bits/main/gbx/gbx_extern.c:341: undefined reference to
>>> `ffi_call'
>>> gbx3-gbx_extern.o:(.rodata+0x50): undefined reference to `ffi_type_void'
>>> gbx3-gbx_extern.o:(.rodata+0x58): undefined reference to
>>> `ffi_type_sint32' gbx3-gbx_extern.o:(.rodata+0x60): undefined reference
>>> to `ffi_type_sint32' gbx3-gbx_extern.o:(.rodata+0x68): undefined
>>> reference to `ffi_type_sint32' gbx3-gbx_extern.o:(.rodata+0x70):
>>> undefined reference to `ffi_type_sint32'
>>> gbx3-gbx_extern.o:(.rodata+0x78): undefined reference to
>>> `ffi_type_sint64' gbx3-gbx_extern.o:(.rodata+0x80): undefined reference
>>> to `ffi_type_float' gbx3-gbx_extern.o:(.rodata+0x88): undefined reference
>>> to `ffi_type_double' gbx3-gbx_extern.o:(.rodata+0x90): undefined
>>> reference to `ffi_type_void' gbx3-gbx_extern.o:(.rodata+0x98): undefined
>>> reference to `ffi_type_pointer' gbx3-gbx_extern.o:(.rodata+0xa0):
>>> undefined reference to `ffi_type_pointer'
>>> gbx3-gbx_extern.o:(.rodata+0xa8): undefined reference to `ffi_type_void'
>>> gbx3-gbx_extern.o:(.rodata+0xb0): undefined reference to `ffi_type_void'
>>> gbx3-gbx_extern.o:(.rodata+0xb8): undefined reference to `ffi_type_void'
>>> gbx3-gbx_extern.o:(.rodata+0xc0): undefined reference to `ffi_type_void'
>>> gbx3-gbx_extern.o:(.rodata+0xc8): undefined reference to
>>> `ffi_type_pointer' gbx3-gbx_extern.o:(.rodata+0xd0): undefined reference
>>> to `ffi_type_pointer' collect2: ld returned 1 exit status
>>> make[4]: *** [gbx3] Error 1
>>>
>>> Thanks
>>>       
>> Hi,
>>
>> I'm on CentOS 5.1 x86_64 again, and have build an rpm for libffi which
>> installs these files:
>> (sources are from sources.redhat.com:/cvs/libffi )
>>
>> /usr/lib64/libffi.la
>> /usr/lib64/libffi.so
>> /usr/lib64/libffi.so.4
>> /usr/lib64/libffi.a
>> /usr/lib64/libffi.so.4.0.1
>> /usr/include/ffi.h
>> /usr/include/ffitarget.h
>>
>> # ldconfig -v|grep ffi
>> /usr/lib64
>>         libffi.so.4 -> libffi.so.4.0.1
>>
>> The ffi .h files are found correctly by gambas make, but the errors
>> above (which I had too), are due to the configure/make process not
>> linking the libffi to gbx2
>> When I tweak the main/gbx/Makefile by adding -lffi on this line:
>>
>> gbx2_LDADD = -lm    -ldl   -lffi
>>
>> the compile of gbx2 succeeds!...
>>
>> Which info/output do I have to sent, so you guys can fix the
>> configure/make files, and I don't have to hack the Makefile manually?
>>
>> CentOS 5.1
>> gambas 2.0 from cvs today
>> gcc version 4.1.2
>>
>> Thanks,
>> Ron.
>>
>>
>>     
>
> Did you ./reconf everything after having installed libffi?
>
>   
Yes, after I run:

./reconf-all
./configure -C
make

It still fails without the hack above, if I grep all output of make and 
configure, I find no sign of detecting or not detecting libffi...

Regards,
Ron.




From scatman at ...571...  Sun Jan 27 11:02:34 2008
From: scatman at ...571... (scatman)
Date: Sun, 27 Jan 2008 11:02:34 +0100
Subject: [Gambas-devel] BUG in IDE Revision 1038
Message-ID: <200801271102.34162.scatman@...571...>

Hello,


instruction:

Load a Projet, go to the Code, Press 

? Key (Left from Backspace keycode 21 (keysym 0xb4, acute))  

and than Arrow  up or down.
Gambas Crashed with SIGSEGV.


Gentoo
Amd X2
qt 3.3.8-r4
glibc 2.7-r1

thanks



From gambas at ...1...  Sun Jan 27 15:00:14 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 27 Jan 2008 15:00:14 +0100
Subject: [Gambas-devel] BUG in IDE Revision 1038
In-Reply-To: <200801271102.34162.scatman@...571...>
References: <200801271102.34162.scatman@...571...>
Message-ID: <200801271500.14963.gambas@...1...>

On dimanche 27 janvier 2008, scatman wrote:
> Hello,
>
>
> instruction:
>
> Load a Projet, go to the Code, Press
>
> ? Key (Left from Backspace keycode 21 (keysym 0xb4, acute))
>
> and than Arrow  up or down.
> Gambas Crashed with SIGSEGV.
>
>
> Gentoo
> Amd X2
> qt 3.3.8-r4
> glibc 2.7-r1
>
> thanks
>

This should be fixed in the revision 1041.

Regards,

-- 
Benoit Minisini



From scatman at ...571...  Sun Jan 27 16:16:16 2008
From: scatman at ...571... (scatman)
Date: Sun, 27 Jan 2008 16:16:16 +0100
Subject: [Gambas-devel] Process Stream (all 64-bit Revision)
Message-ID: <200801271616.16944.scatman@...571...>

Hello,


i think i have found a nother Bug

I am write a little Phone-app...

#### Code for Reading from phone. ####

PUBLIC SUB treeViewOK_Click()

SELECT CASE treeView1.Key

  CASE "Save" 'save the Contact to disk
    saveTelNr()

  CASE "SM" 'read phonememory from phone
    ColumnView1.Clear
    $hProcess = EXEC ["gammu", "--getmemory", "SM", "1", "150", "-nonempty"] 	
FOR READ WRITE
    object.Attach($hProcess, ME, "Contact")

End 

#### Code to Sort the Entries. ####

PUBLIC SUB Contact_Read()

' load via exec gammu --getmemory the Contact

DIM Name AS String
DIM memory AS String
DIM location AS String
DIM entrie AS Integer

WHILE NOT Eof(LAST)
  LINE INPUT #LAST, PhoneData

    ' PhoneData = Conv(PhoneData, system.Charset, desktop.Charset)
    
    PRINT PhoneData
    
    IF Mid$(PhoneData, 12, 8) = "Location" THEN
      location = Right$(PhoneData, 2)
    END IF
     
    IF Left$(PhoneData, 4) = "Name" THEN
      name = Mid$(PhoneData, InStr(PhoneData, ":") + 3, - 1)
    END IF

    IF Left$(PhoneData, 7) = "General" THEN
      number = Mid$(PhoneData, (InStr(PhoneData, ":")) + 3, -1)
    END IF
     
    IF Left$(PhoneData, 6) = "Memory" THEN
      memory = Mid$(PhoneData, (InStr(PhoneData, "Memory")) + 7, 2)
    END IF
    
     IF location <> NULL THEN 
     IF entrie <> Val(location) THEN  
       ColumnView1.Add(Val(location), name)
       Columnview1[Val(location)][1] = number
       ColumnView1[Val(location)][2] = memory
       ColumnView1[Val(location)][3] = location
       label6.Text = Index
       entrie = Val(location)
     END IF
     END IF
        
WEND 

END


Now my Problem.
The Stream is Broken.

#### gammu via console gives me this ###

Memory ME, Location 1
General number       : "+4912345678"
Name                 : "Mr. Mustermann/M"

Memory ME, Location 2
General number       : "012345678"
Name                 : "Firma/W"

and so on.


the Stream inside Gambas looks

Memory ME, Location 1
number       : "+4912345678"
Name                 : "Mr. Mustermann/M"

Memory ME, Location 2
General number       : "012345678"
Name                 : "Firma/W"

But every 10 Locations the Stream is Broken

Memory ME, Location 11
General number    
   : "+4923456789"
Name                 : "DIETER/M"

from 12 to 20 is everything OK.
 
Memory ME, Location 21
General number       : "+49000000000"
Name          
       : "M. Rosenberg/H"

If you need my Project, i can send it.

thanks



From gambas at ...1...  Sun Jan 27 22:16:25 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 27 Jan 2008 22:16:25 +0100
Subject: [Gambas-devel] Process Stream (all 64-bit Revision)
In-Reply-To: <200801271616.16944.scatman@...571...>
References: <200801271616.16944.scatman@...571...>
Message-ID: <200801272216.25256.gambas@...1...>

On dimanche 27 janvier 2008, scatman wrote:
> Hello,
>
>
> i think i have found a nother Bug
>
> I am write a little Phone-app...
>
> #### Code for Reading from phone. ####
>
> PUBLIC SUB treeViewOK_Click()
>
> SELECT CASE treeView1.Key
>
>   CASE "Save" 'save the Contact to disk
>     saveTelNr()
>
>   CASE "SM" 'read phonememory from phone
>     ColumnView1.Clear
>     $hProcess = EXEC ["gammu", "--getmemory", "SM", "1", "150",
> "-nonempty"] FOR READ WRITE
>     object.Attach($hProcess, ME, "Contact")
>
> End
>
> #### Code to Sort the Entries. ####
>
> PUBLIC SUB Contact_Read()
>
> ' load via exec gammu --getmemory the Contact
>
> DIM Name AS String
> DIM memory AS String
> DIM location AS String
> DIM entrie AS Integer
>
> WHILE NOT Eof(LAST)
>   LINE INPUT #LAST, PhoneData
>
>     ' PhoneData = Conv(PhoneData, system.Charset, desktop.Charset)
>
>     PRINT PhoneData
>
>     IF Mid$(PhoneData, 12, 8) = "Location" THEN
>       location = Right$(PhoneData, 2)
>     END IF
>
>     IF Left$(PhoneData, 4) = "Name" THEN
>       name = Mid$(PhoneData, InStr(PhoneData, ":") + 3, - 1)
>     END IF
>
>     IF Left$(PhoneData, 7) = "General" THEN
>       number = Mid$(PhoneData, (InStr(PhoneData, ":")) + 3, -1)
>     END IF
>
>     IF Left$(PhoneData, 6) = "Memory" THEN
>       memory = Mid$(PhoneData, (InStr(PhoneData, "Memory")) + 7, 2)
>     END IF
>
>      IF location <> NULL THEN
>      IF entrie <> Val(location) THEN
>        ColumnView1.Add(Val(location), name)
>        Columnview1[Val(location)][1] = number
>        ColumnView1[Val(location)][2] = memory
>        ColumnView1[Val(location)][3] = location
>        label6.Text = Index
>        entrie = Val(location)
>      END IF
>      END IF
>
> WEND
>
> END
>
>
> Now my Problem.
> The Stream is Broken.
>
> #### gammu via console gives me this ###
>
> Memory ME, Location 1
> General number       : "+4912345678"
> Name                 : "Mr. Mustermann/M"
>
> Memory ME, Location 2
> General number       : "012345678"
> Name                 : "Firma/W"
>
> and so on.
>
>
> the Stream inside Gambas looks
>
> Memory ME, Location 1
> number       : "+4912345678"
> Name                 : "Mr. Mustermann/M"
>
> Memory ME, Location 2
> General number       : "012345678"
> Name                 : "Firma/W"
>
> But every 10 Locations the Stream is Broken
>
> Memory ME, Location 11
> General number
>
>    : "+4923456789"
>
> Name                 : "DIETER/M"
>
> from 12 to 20 is everything OK.
>
> Memory ME, Location 21
> General number       : "+49000000000"
> Name
>
>        : "M. Rosenberg/H"
>
> If you need my Project, i can send it.
>
> thanks
>

Sending the project is always better!

Regards,

-- 
Benoit Minisini



From gambas at ...1...  Sun Jan 27 22:22:00 2008
From: gambas at ...1... (Benoit Minisini)
Date: Sun, 27 Jan 2008 22:22:00 +0100
Subject: [Gambas-devel] Process Stream (all 64-bit Revision)
In-Reply-To: <200801271616.16944.scatman@...571...>
References: <200801271616.16944.scatman@...571...>
Message-ID: <200801272222.00265.gambas@...1...>

On dimanche 27 janvier 2008, scatman wrote:
> Hello,
>
>
> i think i have found a nother Bug
>
> I am write a little Phone-app...
>
> #### Code for Reading from phone. ####
>
> PUBLIC SUB treeViewOK_Click()
>
> SELECT CASE treeView1.Key
>
>   CASE "Save" 'save the Contact to disk
>     saveTelNr()
>
>   CASE "SM" 'read phonememory from phone
>     ColumnView1.Clear
>     $hProcess = EXEC ["gammu", "--getmemory", "SM", "1", "150",
> "-nonempty"] FOR READ WRITE
>     object.Attach($hProcess, ME, "Contact")
>
> End
>
> #### Code to Sort the Entries. ####
>
> PUBLIC SUB Contact_Read()
>
> ' load via exec gammu --getmemory the Contact
>
> DIM Name AS String
> DIM memory AS String
> DIM location AS String
> DIM entrie AS Integer
>
> WHILE NOT Eof(LAST)
>   LINE INPUT #LAST, PhoneData
>
>     ' PhoneData = Conv(PhoneData, system.Charset, desktop.Charset)
>
>     PRINT PhoneData
>
>     IF Mid$(PhoneData, 12, 8) = "Location" THEN
>       location = Right$(PhoneData, 2)
>     END IF
>
>     IF Left$(PhoneData, 4) = "Name" THEN
>       name = Mid$(PhoneData, InStr(PhoneData, ":") + 3, - 1)
>     END IF
>
>     IF Left$(PhoneData, 7) = "General" THEN
>       number = Mid$(PhoneData, (InStr(PhoneData, ":")) + 3, -1)
>     END IF
>
>     IF Left$(PhoneData, 6) = "Memory" THEN
>       memory = Mid$(PhoneData, (InStr(PhoneData, "Memory")) + 7, 2)
>     END IF
>
>      IF location <> NULL THEN
>      IF entrie <> Val(location) THEN
>        ColumnView1.Add(Val(location), name)
>        Columnview1[Val(location)][1] = number
>        ColumnView1[Val(location)][2] = memory
>        ColumnView1[Val(location)][3] = location
>        label6.Text = Index
>        entrie = Val(location)
>      END IF
>      END IF
>
> WEND
>
> END
>
>
> Now my Problem.
> The Stream is Broken.
>
> #### gammu via console gives me this ###
>
> Memory ME, Location 1
> General number       : "+4912345678"
> Name                 : "Mr. Mustermann/M"
>
> Memory ME, Location 2
> General number       : "012345678"
> Name                 : "Firma/W"
>
> and so on.
>
>
> the Stream inside Gambas looks
>
> Memory ME, Location 1
> number       : "+4912345678"
> Name                 : "Mr. Mustermann/M"
>
> Memory ME, Location 2
> General number       : "012345678"
> Name                 : "Firma/W"
>
> But every 10 Locations the Stream is Broken
>
> Memory ME, Location 11
> General number
>
>    : "+4923456789"
>
> Name                 : "DIETER/M"
>
> from 12 to 20 is everything OK.
>
> Memory ME, Location 21
> General number       : "+49000000000"
> Name
>
>        : "M. Rosenberg/H"
>
> If you need my Project, i can send it.
>
> thanks
>

Beware! 

When you use LINE INPUT, you read a line that is ended by an "end-of-line" 
character, or by the end of the stream. In other words, LINE INPUT does not 
block until an end-of-line is reached. Maybe I should make a property for 
that in the Stream class, but I don't at the moment.

During the call to Contact_Read, not the entire output of the process is 
available, so you could get part of a line.

To know if you really read a full line, or if you reached the end of the 
stream because the running process did not send all its data yet, you must 
use the Process.EndOfFile property. See the documentation of this property 
for more details.

Regards,

-- 
Benoit Minisini



From scatman at ...571...  Mon Jan 28 15:36:21 2008
From: scatman at ...571... (scatman)
Date: Mon, 28 Jan 2008 15:36:21 +0100
Subject: [Gambas-devel] Process Stream (all 64-bit Revision)
In-Reply-To: <200801272216.25256.gambas@...1...>
References: <200801271616.16944.scatman@...571...>
	<200801272216.25256.gambas@...1...>
	(sfid-20080128_152233_303927_828BC0228E4BC2D)
Message-ID: <200801281536.21734.scatman@...571...>

Am Sonntag, 27. Januar 2008 schrieb Benoit Minisini:

> > If you need my Project, i can send it.
> >
> > thanks
>
> Sending the project is always better!
>

OK, here is it.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnoxi_2.tar.bz2
Type: application/x-tbz
Size: 19853 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20080128/fd07f139/attachment.bin>

From tcallawa at ...360...  Wed Jan 30 21:38:03 2008
From: tcallawa at ...360... (Tom Callaway)
Date: Wed, 30 Jan 2008 15:38:03 -0500
Subject: [Gambas-devel] Drop ancient README.REDHAT and README.FEDORA
Message-ID: <1201725483.3297.39.camel@...575...>

Hi Gambas developers!

Is there any way we could drop the really old README.REDHAT and
README.FEDORA files? They're really ancient and not even remotely
correct anymore.

Thanks,

~spot (the Fedora gambas maintainer)




From henrique.andreassy at ...241...  Wed Jan 30 21:39:34 2008
From: henrique.andreassy at ...241... (=?utf-8?B?RWRpc29uIEhlbnJpcXVlIEFuZHJlYXNzeSAoQ2V0aWwgLSBTdXBvcnRlIFTDqWNuaWNvKQ==?=)
Date: Wed, 30 Jan 2008 18:39:34 -0200
Subject: [Gambas-devel] Drop ancient README.REDHAT and README.FEDORA
Message-ID: <943625457@...241...>

Esse funcion?rio temporariamente n?o estar? acessando seus e-mails, os quais entretanto est?o sendo recebidos e armazenados em sua caixa postal. Posteriormente, quando de seu retorno ? empresa, o destinat?rio ir? acess?-los.
Caso haja necessidade urgente, entre em contato com outro colaborador da mesma equipe.




From gambas at ...1...  Wed Jan 30 21:42:36 2008
From: gambas at ...1... (Benoit Minisini)
Date: Wed, 30 Jan 2008 21:42:36 +0100
Subject: [Gambas-devel] Drop ancient README.REDHAT and README.FEDORA
In-Reply-To: <1201725483.3297.39.camel@...575...>
References: <1201725483.3297.39.camel@...575...>
Message-ID: <200801302142.36519.gambas@...1...>

On mercredi 30 janvier 2008, Tom Callaway wrote:
> Hi Gambas developers!
>
> Is there any way we could drop the really old README.REDHAT and
> README.FEDORA files? They're really ancient and not even remotely
> correct anymore.
>
> Thanks,
>
> ~spot (the Fedora gambas maintainer)
>

No problem. I remove the files.

Regards,

-- 
Benoit Minisini



From tcallawa at ...360...  Wed Jan 30 22:17:01 2008
From: tcallawa at ...360... (Tom Callaway)
Date: Wed, 30 Jan 2008 16:17:01 -0500
Subject: [Gambas-devel] x86_64 success
Message-ID: <1201727821.3297.44.camel@...575...>

I've managed to get the gambas 2.0.0 code (svn checkout 1043) running on
my x86_64 laptop (built 64bit). Is there a test suite that I could put
it through to see how functional it is?

Thanks in advance,

~spot




From gambas at ...1...  Wed Jan 30 22:44:58 2008
From: gambas at ...1... (Benoit Minisini)
Date: Wed, 30 Jan 2008 22:44:58 +0100
Subject: [Gambas-devel] x86_64 success
In-Reply-To: <1201727821.3297.44.camel@...575...>
References: <1201727821.3297.44.camel@...575...>
Message-ID: <200801302244.58770.gambas@...1...>

On mercredi 30 janvier 2008, Tom Callaway wrote:
> I've managed to get the gambas 2.0.0 code (svn checkout 1043) running on
> my x86_64 laptop (built 64bit). Is there a test suite that I could put
> it through to see how functional it is?
>
> Thanks in advance,
>
> ~spot
>

You can try all examples. You will see that the networking components do not 
really work on 64 bits yet.

Regards,

-- 
Benoit Minisini



From tcallawa at ...360...  Wed Jan 30 23:01:30 2008
From: tcallawa at ...360... (Tom "spot" Callaway)
Date: Wed, 30 Jan 2008 17:01:30 -0500
Subject: [Gambas-devel] x86_64 success
In-Reply-To: <200801302244.58770.gambas@...1...>
References: <1201727821.3297.44.camel@...575...>
	<200801302244.58770.gambas@...1...>
Message-ID: <1201730490.3297.50.camel@...575...>


On Wed, 2008-01-30 at 22:44 +0100, Benoit Minisini wrote:
> On mercredi 30 janvier 2008, Tom Callaway wrote:
> > I've managed to get the gambas 2.0.0 code (svn checkout 1043) running on
> > my x86_64 laptop (built 64bit). Is there a test suite that I could put
> > it through to see how functional it is?
> >
> > Thanks in advance,
> >
> > ~spot
> >
> 
> You can try all examples. You will see that the networking components do not 
> really work on 64 bits yet.

Thanks! Hopefully those components will work soon.

One other question:

Is it ok if I continue to name the package "gambas" in Fedora as opposed
to "gambas2". This way, there is a clean upgrade path, since no one is
supporting gambas1 anymore.

Thanks,

~spot




From gambas at ...1...  Wed Jan 30 23:11:40 2008
From: gambas at ...1... (Benoit Minisini)
Date: Wed, 30 Jan 2008 23:11:40 +0100
Subject: [Gambas-devel] x86_64 success
In-Reply-To: <1201730490.3297.50.camel@...575...>
References: <1201727821.3297.44.camel@...575...>
	<200801302244.58770.gambas@...1...>
	<1201730490.3297.50.camel@...575...>
Message-ID: <200801302311.40277.gambas@...1...>

On mercredi 30 janvier 2008, Tom "spot" Callaway wrote:
> On Wed, 2008-01-30 at 22:44 +0100, Benoit Minisini wrote:
> > On mercredi 30 janvier 2008, Tom Callaway wrote:
> > > I've managed to get the gambas 2.0.0 code (svn checkout 1043) running
> > > on my x86_64 laptop (built 64bit). Is there a test suite that I could
> > > put it through to see how functional it is?
> > >
> > > Thanks in advance,
> > >
> > > ~spot
> >
> > You can try all examples. You will see that the networking components do
> > not really work on 64 bits yet.
>
> Thanks! Hopefully those components will work soon.
>
> One other question:
>
> Is it ok if I continue to name the package "gambas" in Fedora as opposed
> to "gambas2". This way, there is a clean upgrade path, since no one is
> supporting gambas1 anymore.
>
> Thanks,
>
> ~spot
>

No, you must keep the exact naming of all packages as specified in the "how to 
package gambas" document on the wiki. 

For two reasons:

- The RPM packages generated by the IDE rely on that naming.

- Gambas2 is not an upgrade of Gambas1, but a different version, and both 
version should be able to be installed on the same system.

Regards,

-- 
Benoit Minisini



From gianlucarenzi at ...576...  Thu Jan 31 09:24:28 2008
From: gianlucarenzi at ...576... (Gianluca)
Date: Thu, 31 Jan 2008 09:24:28 +0100
Subject: [Gambas-devel] Gambas on ARM target
Message-ID: <200801310924.28824.gianlucarenzi@...576...>

It is my first time writing on this mailing list.
As a _nerd_ I am delveloping an embedded ARM9 cpu board.
I would like to know how to cross compile/use Gambas on
that platform.

Usually I am working on a standard PC, so I would like to
develop my gambas application on the desktop PC, then move it
to embedded platform.
I would like to know what are the needed steps to use this 
application on ARM9 platform.

Some time ago, I tried to cross-compile gambas
(using the configure switch --host arm-linux) but it failed.

Does anybody are using Gambas on an architecture different from
standard x86 PC? Can anybody point me out of this?

Best regards,
-- 
Gianluca Renzi



From sourceforge-raindog2 at ...19...  Thu Jan 31 16:18:10 2008
From: sourceforge-raindog2 at ...19... (Rob)
Date: Thu, 31 Jan 2008 10:18:10 -0500
Subject: [Gambas-devel] Gambas on ARM target
In-Reply-To: <200801310924.28824.gianlucarenzi@...576...>
References: <200801310924.28824.gianlucarenzi@...576...>
Message-ID: <200801311018.10059.sourceforge-raindog2@...19...>

On Thursday 31 January 2008 03:24, Gianluca wrote:
> Does anybody are using Gambas on an architecture different from
> standard x86 PC? Can anybody point me out of this?

Someone did port Gambas to PowerPC a few years ago, though I think 
they did the building on the PPC itself rather than crosscompiling. 

If you're successful, please share with the list, because I've been 
hoping to do it myself (to try to cram Gambas and gb.sdl onto the 
ARM9 Nintendo DS, with or without DSLinux.)  I've just been waiting 
for a DS emulator that runs well enough under Linux to run DSLinux, 
and one was recently released that claims to do so.

If I get there first, I'll do the same, but I'll probably try to pick 
up the ODF component again first.

Rob



From gianlucarenzi at ...576...  Thu Jan 31 16:44:28 2008
From: gianlucarenzi at ...576... (Gianluca)
Date: Thu, 31 Jan 2008 16:44:28 +0100
Subject: [Gambas-devel] Gambas on ARM target
In-Reply-To: <200801311018.10059.sourceforge-raindog2@...19...>
References: <200801310924.28824.gianlucarenzi@...576...>
	<200801311018.10059.sourceforge-raindog2@...19...>
Message-ID: <200801311644.28964.gianlucarenzi@...576...>

On Thursday 31 January 2008 16:18, Rob wrote:
> On Thursday 31 January 2008 03:24, Gianluca wrote:
> > Does anybody are using Gambas on an architecture different from
> > standard x86 PC? Can anybody point me out of this?
> 
> Someone did port Gambas to PowerPC a few years ago, though I think 
> they did the building on the PPC itself rather than crosscompiling. 
I understand. But it is not a viable way to me.
The target processor has 64MB SDRAM and 128MB Flash as a mass storage device
and it is running at 300Mhz. To compile Gambas on target I will need
native GCC, GNUtools and whatever else... mmh... too big and too slow.

I need to run an executable.

I don't need to have an IDE or RAD to develop in an embedded board.
The only thing I need is some library and an executable just to run the gambas project...

I have already qt-embedded, so I have the half way done... :)

> If you're successful, please share with the list, because I've been 
> hoping to do it myself (to try to cram Gambas and gb.sdl onto the 
> ARM9 Nintendo DS, with or without DSLinux.)  I've just been waiting 
> for a DS emulator that runs well enough under Linux to run DSLinux, 
> and one was recently released that claims to do so.
I could use openmoko emulator (qemu and scratchbox) just to compile natively
on an emulated system, then pass the executable onto the real system...
I think this is *not* the right way to let the things done.

 
> If I get there first, I'll do the same, but I'll probably try to pick 
> up the ODF component again first.
give me a mail, if you will be the first.

Regards,
-- 
Gianluca Renzi



From sourceforge-raindog2 at ...19...  Thu Jan 31 16:58:35 2008
From: sourceforge-raindog2 at ...19... (Rob)
Date: Thu, 31 Jan 2008 10:58:35 -0500
Subject: [Gambas-devel] Gambas on ARM target
In-Reply-To: <200801311644.28964.gianlucarenzi@...576...>
References: <200801310924.28824.gianlucarenzi@...576...>
	<200801311018.10059.sourceforge-raindog2@...19...>
	<200801311644.28964.gianlucarenzi@...576...>
Message-ID: <200801311058.35054.sourceforge-raindog2@...19...>

On Thursday 31 January 2008 10:44, Gianluca wrote:
> I could use openmoko emulator (qemu and scratchbox) just to compile
> natively on an emulated system, then pass the executable onto the
> real system... I think this is *not* the right way to let the
> things done.

I agree, and with the DS having only 4MB of RAM (up to 20 with an 
expansion cartridge that also includes a MicroSD host) I would 
certainly have to crosscompile.  But I'd still want an emulator to 
test my executables.

Rob