Fw: linking against shared libraries

Fw: linking against shared libraries

[Robert Collins]

Forwarded for Gary Vaughan
----- Original Message -----
From: "Gary V. Vaughan" <gvv@techie.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin@sources.redhat.com>
Sent: Sunday, September 17, 2000 11:07 AM
Subject: Re: linking against shared libraries


> 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@techie.com
>  / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___
gary@gnu.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@sourceware.cygnus.com