Re: linking against shared libraries

[Chris Faylor <cgf at cygnus dot com>]

On Sun, Sep 17, 2000 at 01:07:35AM +0100, Gary V. Vaughan wrote:
>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).

Chuck Wilson has put a lot of time, energy, and thought into DLL and
library naming.  I hope that we (i.e., he) will have a chance to review
these fixes before they become an official part of libtool.

Or, who knows, maybe Paul is just going to implement Chuck's suggestions.
The libglib.dll.a was something that he suggested.

>> 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.

AFAIK, dlopen and dlsym should act basically like their linux
counterparts, at least at their simplest.  The second argument to dlopen
is ignored which means you can't use stuff like RTLD_LAZY, etc.

dlsym() should be identical, at least as far as I can tell from the docs.

>>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...

This sounds like a simple use of dlsym.  I must be missing something.
dlsym() just resolves to GetProcAddress.  You give GetProcAddress the
name of a symbol that you want the load address for.  You don't specify
the _imp part.  I belive in the above case you should just be able
to say foo = dlsym(handle, "_g_module_close");

>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.

I've found one patch from you in the ChangeLogs (circa 1998) and no hint
of still unresolved issues in my mail logs.  I guess I'll have to search
the archives to find out what they are.

However, are you saying that you've published a document which
references Cygwin but are telling people to steer clear of the dlopen
implementation?  Ouch.  I really like to fix bugs in Cygwin rather than
tell people to use the Windows versions of functions.

I hope that we can resolve whatever issues there are in dl* for cygwin.
I rewrote the dynamic library loading part of cygwin for 1.1.3 so I'm
now familiar with how the code operates or is supposed to operate.  The
previous implementation was a little hard to follow, IMO.

cgf
(aka Cygwin Engineering Manager)

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com