Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <007701c0209d$4dfc0450$f7c723cb@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Gary V. Vaughan" <gvv AT techie DOT com>, <cgf AT cygnus DOT com>
Cc: <cygwin AT sources DOT redhat DOT com>
References: <012a01c02033$936effc0$f7c723cb AT lifelesswks> <20000917010735 DOT G606 AT demon DOT co DOT uk> <20000916234420 DOT A23827 AT cygnus DOT com> <20000917122440 DOT I606 AT demon DOT co DOT uk>
Subject: Re: linking against shared libraries
Date: Sun, 17 Sep 2000 22:49:12 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-OriginalArrivalTime: 17 Sep 2000 11:47:44.0790 (UTC) FILETIME=[17D0FB60:01C0209D]

I will endeavour to explore libtldl within gmodule next weekend....

Thanks for the hints.

Rob
----- Original Message -----
From: "Gary V. Vaughan" <gvv AT techie DOT com>
To: <cgf AT cygnus DOT com>
Cc: <cygwin AT sources DOT redhat DOT com>; <robert DOT collins AT itdomain DOT com DOT au>
Sent: Sunday, September 17, 2000 10:24 PM
Subject: Re: linking against shared libraries


> 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 AT gnu DOT org list to discuss these sorts of changes on, and
> a libtool-commit AT gnu DOT 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 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