This is the mail archive of the cygwin-developers@cygwin.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]

dlsym discussion..


I've been digging into libtool, trying to get a handle (no pun intended)
on dynamic module loading and related issues. This is for another
project, but cygwin is one of the supported platforms...

Anyway I've uncovered a nasty issue in the cygwin dlsym()
implementation.

Using http://www.opengroup.org/onlinepubs/7908799/xsh/dlsym.html as my
guide, it's my understanding that the following:

handle=dlopen(NULL, ..)
foo=dlsym(handle, "symbol_in_linked_shared_library")

should resolve foo to the symbol in the linked shared library. However
GetProcAddress only resolves symbols in the module pointed to by handle.
this means that applications have to be aware of the dependencies of
modules they load in order to be sure of resolving "passed thru"
symbols. An example of such is a library that just adds a couple of
functions to an existing API, and doesn't wrap the original API at all.
(It shouldn't need to).

Lemma: I spent a bit of time chasing a dead end - tring to resolve
"main" - until I realised that gcc/libtool doesn't by default export any
functions in the .exe. (In fact I'm not sure how to get it to export
them). Such exporting would allow backlinking, which can be handy, even
if it isn't all-that-portable.

Thoughts? I'm a bit hesitant at trying to second guess what dll's have
been implicitly loaded by the Win32System, but if that information is
readily available to cygwin, I'm happy to code up a iterating dlsym()...

Rob


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