X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Fri, 5 Feb 2010 09:39:00 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: dlsym: symbols in dependencies Message-ID: <20100205143900.GB28366@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4B6A857F DOT 2030509 AT users DOT sourceforge DOT net> <20100205091425 DOT GN28659 AT calimero DOT vinschen DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100205091425.GN28659@calimero.vinschen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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