dlsym discussion..

Christopher Faylor cgf@redhat.com
Sun Jun 3 06:48:00 GMT 2001


On Sun, Jun 03, 2001 at 05:22:37PM +1000, Robert Collins wrote:
>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().

cygwin keeps a list of DLLs loaded via dlopen.  It could register other
modules via dll_entry() but that is not a foolproof method due to load
order problems.

cgf



More information about the Cygwin-developers mailing list