Re: dlsym: symbols in dependencies

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Feb  4 02:29, Yaakov S wrote:
> Per POSIX:
> 
> """The dlsym() function shall search for the named symbol in all
> objects loaded automatically as a result of loading the object
> referenced by handle (see dlopen )."""
> 
> With the relevant part of dlopen() saying:
> 
> """Note that some implementations permit the construction of
> dependencies between such objects that are embedded within files. In
> such cases, a dlopen() operation shall load such dependencies in
> addition to the object referenced by file."""
> 
> IOW, when the target of dlopen() has linked dependencies, not only
> shall those dependencies must also be loaded by dlopen() but the
> symbols therein found by dlsym().  On Cygwin, by the nature of
> PE/COFF the dependencies are loaded, but dlsym() does not search
> their symbols.

Looks like a bug in Cygwin.  Sort of.  Or rather, nobody asked for
this functionality yet.

The dlsym function only searches all modules loaded into the process if
the pseudo handle RTLD_DEFAULT has been specified.  If a valid module
handle is given, it only looks in that very DLL.  The underlying Win32
function GetProcAddress does not walk dependencies, unfortunately.

The question is if EnumProcessModules returns the modules in an order,
which allows to draw conclusions about dependencies.  If so, an
easy solution would be to call EnumProcessModules and start the search
at the given module handle in the returned module handle array.  This
would also allow for an easy implementation of RTLD_NEXT.

But somehow I doubt that it's so simple.  Did anybody test something
like that already?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple