This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: linking against shared libraries


On Sun, Sep 17, 2000 at 12:24:40PM +0100, Gary V. Vaughan wrote:
>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.

Thanks.  I missed the libtool-patches list.  I'll subscribe now.

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

Thanks.

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

Wow, the adding of the appropriate prefix makes this well worth it.
Seriously.  It always drives me crazy trying to figure out when it
is needed or when it isn't.  It's the symptom of having to work on
too many different platforms.  I can see why lt_dlsym would be useful.

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

I'm sure there are probably a few subtle and not-so-subtle problems with
dl* stuff.  I don't think it gets the same workout of other parts of the
library.

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

Ok.  Thanks for the clarification. It sounds like you have a nice
implementation.

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

Actually, I mischaracterized this.  I rewrote the backend that loads
the library.  It may not be any clearer but at least *I* understand
it now and I'm willing to support it.  The major improvement to
the dl* stuff in the last year or so was an attempt to provide proper
behavior after a fork.

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

That's probably an undeserved vote of confidence, but thanks.

I hope that this thread results in some dl* bug reports, actually.

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

Is this a characteristic of normal linux/UNIX dlsym?  If so, I'd be
very grateful with any improvements you can make.

cgf

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]