Re: linking against shared libraries

["Gary V. Vaughan" <gvv at techie dot com>]

On Sat, Sep 16, 2000 at 11:44:20PM -0400, Chris Faylor wrote:
> 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.

Certainly.  They will be evaluated by myself and Alexandre Oliva
before they get committed to the cvs repository.  There is a
libtool-patches@gnu.org list to discuss these sorts of changes on, and
a libtool-commit@gnu.org list for tracking what actually gets added.

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

I have archived Chuck's posts and will implement them myself before I
release libtool-1.4, if Paul is busy with pw32.

> >> 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");

If you were to replace the gmodule internals with libltdl, it would
take care of all this for you:

	lt_dlsym (handle, "g_module_close");
	
will DTRT on win32 (adding a "_" prefix) and on the other
architectures to which libltdl has been ported (including some with
no native dlopen type interface).

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

That would be it -- Wow, 2 years ago?  Time flies!.  I'm afraid I
can't recall specifically what were the "issues" I still had.  I do
recall that libltdl became confused if it had two dlopen interfaces
(the LoadLibrary() and cygwin dlopen()) on one architecture, but I
think there was more to it than that. 

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

No.  I didn't mean to imply that.  I *do* strongly advocate the use of
libltdl for all runtime dynamic loading in portable C code (not just
on Cygwin, but for any portable code that wants to do runtime module
loading).  It is a richer API than both dlopen and LoadLibrary, and
takes care of symbol prefix differences, library naming extensions and
search path differences between all of the architectures it supports.
I put a lot of effort into getting it to behave well on Cygwin (circa
1998 it seems!), and I believe it works very well...  It does cut
straight through to the LoadLibrary iface for its internals (so it
works with mingw32 as well), but none of that is exposed to the user. 

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

I didn't know the dlopen iface had been redone for the new net
release.  Cool.  I did struggle with the old code (mostly because I
don't know the win32 api at all).  Whatever hurdles I stumbled over
were in the previous implementation, are more than likely resolved in
your reimplementation -- if indeed they weren't because of my own
misunderstandings.

If you are interested, I will add an entry to my TODO list to see if I
can take some of the nicities from the libtldl LoadLibrary wrapper
code and apply them to the Cygwin LoadLibrary wrapper?  (Automatic `_'
prefixing for example).

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