Mail Archives: cygwin/2000/09/16/22:20:17
Cc:ing the list may very well bounce for me. Robert, if you don't see
this reflected on the list, would you forward it for me please? TIA.
On Sun, Sep 17, 2000 at 10:12:23AM +1100, Robert Collins wrote:
> Gary thanks for your tips on libtool... I have it _mostly_ working. There
> are two issues I've found during my work on glib. (BTW the long delay is
> becuase this is a 'spare time project'
No problem.
> 1. Linking against installed shared libraries without libtool fails however.
>
> ld finds the .a file, not the .dll file.
>
> example: using testglib.c from the glib 1.2.8 tarball.
>
> gcc testglib.c -o
> testglib.exe -I/usr/local/include -I/use/local/lib/g;lib/include -lglib
>
> usr/local/lib is in my ld run path.. GCC correctly finds the library
> functions., and looks for the _imp_ prefix in front of exported variables
> (as per the .h file) but can't find the exported variables.
> ld fails to find 0lglib if libglib.a is renamed, but libglib.la and
> libglib-1-2-0-0-8.dll are present.
>
> running libtool gcc testglib.c -o
> testglib.exe -I/usr/local/include -I/use/local/lib/g;lib/include
> /usr/local/lib/libglib.la
> causes
> gcc testglib.c -o testglib.exe -I/usr/local/include -I
> /usr/local/lib/glib/include
> /usr/local/lib/libglib-1-2-0-0-8.dll -Wl,--rpath -Wl,/usr/local/lib -Wl,--rp
> ath -Wl,/usr/local/lib
> To be run, which works correctly.
>
> Running the first command, replacing -lglib with
> /usr/local/lib/libglib-1-2-0-0-8.dll works.
> Equally renaming the -1-2-0-0-8.dll to libglib.dll works.
>
> I suspect this is either a libtool dll naming issue or a ld search order
> issue. Unfortunately I don't have the spare time to dig into it.
Both! Cygwin ld prefers libfoo.a over libfoo.dll for esoteric reasons
beyond my ken. Also, libtool names dll's stupidly on Cygwin, which
makes it hard for non libtool linked apps to find them. Paul
Sokolovsky is working on some fixes for this in libtool (which would
involve installing a libglib.dll.a in your case).
> 2. I'm having problems with dlsym/dlopen et al.
>
> Can anyone point me to some references on using dlsym/dlopen under cygwin
> with libtool generated dll's?
> Ok so maybe a reference guide is a bit hopeful.
> I'm happy to keep reading the various disparate bits of doco floating around
> but narrowing the search would help.
I have written some very comprehensive docs on dlopen, libltdl and
Cygwin in `Autoconf, Automake and Libtool' <plug>(which is available on
preorder from amazon.com)</plug>.
When writing the Cygwin dynamic loader module for libltdl, I couldn't
get the cygwin dlopen wrappers to work (I did submit some patches but
there were still unresolved issues). I simply used the LoadLibrary
API directly.
> Specifically are there any quirks with dlopen/dlsym on cygwin (other than
> the library being a .dll not a .so?)
>
> The call that is stumping me at the moment is dlsym (handle to self,
> "g_module_close"). nm shows a _g_module_close and a _imp__g_module_close in
> the test .exe
> The purpose is to retrieve the symbol address, of a dynamically bound
> function...
I have wanted to rewrite gmodule as a libltdl wrapper for ages, but
haven't yet found the time. libltdl is far more powerful and general
(it can emulate dlopening even if you link statically for instance --
which makes debugging a breeze; and it works on beos, all flavours of
windows, hpux, etc, etc.), so it seems silly for gtk to drag around
gmodule like a broken leg, when it would be quite straight forward to
rewite the gmosule API in terms of libltdl -- a good weekend project
in fact.
I haven't mentioned this to the gtk+ maintainers however, so anyone
who takes on the project should check that it will be accepted into
the upstream sources before doing any work on it.
Failing that, it is on my TODO list after releasing libtool-1.4,
m4-1.5, snprintfv-1.0 and my next book. Hmm. That would be several
months away then =(O|
> FWIW I'm working on getting libgmodule working, I've successfully built the
> whole gnome-base and core-apps tarballs. (without dynamic libraries... and
> thus libgmodule is needed) Once gmodule is working there should be full
> (-sound) gnome capabilities for an NT based system (with Cygwin/XFree86).
Cool.
Cheers,
Gary.
--
___ _ ___ __ _ mailto: gvv AT techie DOT com
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ gary AT gnu DOT org
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -