[Gambas-devel] Yet more Cygwin[RESEND]

Brandon Bergren bdragon at ...185...
Mon Nov 29 01:45:18 CET 2004


Quoting Benoit Minisini <gambas at ...1...>:

> On Friday 26 November 2004 03:19, Brandon Bergren wrote:
> > Didn't seem to go through -- resending
> > --Brandon
> >
> > ===================
> > Info files generated:
> > gb.compress
> > gb.db
> > gb.debug
> > gb.eval
> > gb <-- Doesn't crash gbi now! :)
> > gb.net <-- Functionally broken; I had to comment out some stuff. Cygwin
> > lacks a couple of reentrant functions, have to look into more later.
> > gb.vb
> >
> > Currently broken:
> > gb.qt <-- link issues. It might be my fault, I was using a binary release,
> > and the problems I'm getting look ABI related. I'm going to compile QT
> from
> > scratch tonight and see if that fixes it.
> > gb.sdl <-- I have it disabled while I do other things.
> >
> > To fix the crash I was having with gbi, I had to upgrade libltdl, make
> > distclean, and reconfigure.
> >
> > Also, I still have to manually #define USE_LTDL 1 in config.h.
> 
> I should add the option to configure...

Or grep the code for USE_LTDL and decide whether you REALLY need to be directly
loading the .so's there.  If gambas is using LTDL everywhere nowadays, it
should be safe to just test with the USE_LTDL path enabled and remove the other
stuff if it still works on all tested platforms, yes?  (Remember, Cygwin shared
libraries DONT have .so in them -- but opening the .la will get you the correct
module automagically.)
Judging by gbi.c, you originally did things by hand (dlopen()), and then
switched to LTDL, right?

Um, on the same note, would you accept patches from me to simplify gbi.c? I've
spent WAY too much time in that file, it's growing on me.  I understand how it
works now. Scary. ;P  There's some cruft in there, and it could use some
documentation comments in certain sections.


> 
> >
> > The newest stable, Libtool 1.5.10, works great in cygwin.  I manually
> > copied /usr/local/share/libtool/libltdl into place, but normally you
> > upgrade with 'libtoolize --ltdl', right?  The version in the gambas tree
> > has a copyright date of 2000 (!)
> >
> > Libtool can be had at:
> > http://www.gnu.org/software/libtool/libtool.html
> >
> > After upgrading libltdl, I had to comment out the two 'lt_dlopen_flag ='
> > lines in the code.
> > I think those aren't required anymore, and it doesn't appear to exist in
> > ltdl.h anymore.
> >
> 
> Actually, I modified the libltdl sources by adding a lt_dlopen_flag that 
> allows me to pass the LTDL_LAZY flag to dlopen() when calling lt_dlopen(). 
> Otherwise, all symbols are resolved at library loading, which can be slow 
> when loading the qt or kde libraries.
> 
Oh, heh heh. I see.  Didn't notice there were local mods.


> I will try to download and merge libtool 1.5.10 in the package as soon as 
> possible. I tried an little older version some times ago, but failed to 
> merge.
> 
Don't use too much time on that, though.

It looks like the upcoming libtool 2.0 will be the way to go.  I've kinda been
following their progress the last week, and some exciting stuff is happening. 
I have a feeling that libtool/autotools will have a major release Real Soon
Now, with better Windows support.

When the 2.x branch of libtool is finalised, all this shared library stuff on
Windows should be way easier. (grain of salt, please)

I'm currently testing the latest cygwin experimental libtool stuff (and learning
more about how this all fits together)

Hopefully, the bleeding edge stuff will be able to handle the problem I'm having
with QT better. (DLLs with C++ dependencies are a MAJOR PITA in Cygwin.)

Thanks for putting up with all my shots in the dark -- I'm learning a lot here.

> Regards,
> 
> -- 
> Benoit Minisini
> mailto:gambas at ...1...
> 
> 
Thanks,
--Brandon Bergren




More information about the Devel mailing list