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
