linking against shared libraries

linking against shared libraries

[Robert Collins]

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'

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.

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.

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


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




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

Re: linking against shared libraries

[Gary V. Vaughan]

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

Re: linking against shared libraries

[Chris Faylor]

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

Re: linking against shared libraries

[Gary V. Vaughan]

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

Re: linking against shared libraries

[Robert Collins]

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

Thanks for the hints.

Rob
----- Original Message -----
From: "Gary V. Vaughan" <gvv@techie.com>
To: <cgf@cygnus.com>
Cc: <cygwin@sources.redhat.com>; <robert.collins@itdomain.com.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@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

Re: linking against shared libraries

[Chris Faylor]

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

Re: linking against shared libraries

[Fergus Henderson]

On 17-Sep-2000, Chris Faylor <cgf@cygnus.com> wrote:
> On Sun, Sep 17, 2000 at 12:24:40PM +0100, Gary V. Vaughan wrote:
> >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?

AFAIK, Unix systems that support dlopen() don't prefix C symbol
names with `_' when compiling them to assembler in the first place,
so the issue is moot.  At least this is the case on Solaris (2.7),
Linux (>= libc6), and OSF1 (3.2 ), which are the systems that
I have easily available right now.  dlopen() originated on Solaris,
according to the Linux man page.

On systems such as Cygwin which do prefix C names with `_' when
compiling to assembler, whether dlopen() should prefix the name with an
underscore depends on whether the name that the user is trying to look
up is an assembly name or a C name.  If it's a C name, then it's right
for dlopen() to prefix the name with an underscore, to match what the
C compiler does, but if it's an assembly name, then doing that would
be wrong.  Unfortunately the interface to dlopen() provides the
dlopen() implementation with no clues as to which one the user meant.
The documentation for dlopen() says that the argument is the "symbol
name", which is ambiguous, but could be read as implying that it is
supposed to be the assembly name.  However, in practice most uses of
dlopen() tend to be passing C names rather than assembler names.

Probably most uses of dlopen() are for C names, and so inserting
the prefix would work well in most cases.  However, inserting the
prefix would also make it impossible to look up assember names that
don't start with underscore using dlopen().

It's a bit like the issue of text-versus-binary:
the original unix-only interface didn't need to distinguish
between the different cases (text/binary or C/asm/whatever),
but in the Windows environment, you do need to make such
distinctions.  So some programs will need source modifications.
The best you can do is to choose the default carefully,
and make it easy to override the default for programs for which
the default is not appropriate.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

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

Re: linking against shared libraries

[Chris Faylor]

On Mon, Sep 18, 2000 at 11:11:21AM +0100, Fifer, Eric wrote:
>
>Chris Faylor wrote:
>>I hope that we can resolve whatever issues there are in dl* for cygwin.
>
>Just as a testimonial, Perl uses the dl* routines successfully.
>
>Also, if you bypass dlopen() and go straight to LoadLibrary(),
>fork() will not work correctly.

Right.  Unless I wanted to provide a wrapper for LoadLibrary (which I
don't) this will always be the case.

The problem is that, for some reason, Windows loads DLLs in different
spots in the "parent" and "child" when you do a "fork".  It has every
right to do this, of course, but it screws up fork.

I went to considerable effort to work around this last year by
instituting an ugly hack in the fork code which worked around this.
My main motivation for getting this working was perl since I am a
very long time perl user.

cgf

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

RE: linking against shared libraries

[Fifer, Eric]

Chris Faylor wrote:
>I hope that we can resolve whatever issues there are in dl* for cygwin.

Just as a testimonial, Perl uses the dl* routines successfully.

Also, if you bypass dlopen() and go straight to LoadLibrary(),
fork() will not work correctly.

Eric Fifer


__________________________________________________________________________________

IMPORTANT: This email is confidential and may also be legally privileged. If you have received this email in error, you are on notice of its status. If you are not the intended recipient, please notify us immediately by reply email or by telephoning Sanwa International plc's IT Helpdesk on +44 (20) 7330 0444. Then delete this email from your system. You should not copy it or use it for any purpose or disclose its contents to any other person.

Any views contained herein, express or implied, are those of the author and may not necessarily reflect those of Sanwa International plc. Sanwa International plc reserves the right to monitor all emails within its network. Email may be susceptible to virus infection, data corruption, interception and unauthorised amendment. Sanwa International plc does not accept liability for any such infection, corruption, interception or amendment or the consequences thereof.

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