On Fri, Feb 05, 2010 at 10:14:25AM +0100, Corinna Vinschen wrote: >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?
We have the functionality to find DLL dependencies. It just won't be easy to link it to dlsym. I'll add it to my todo though. I vaguely recall that someone else asked for this in the past. cgf -- 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