Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Sun, 3 Jun 2001 09:48:42 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT sources DOT redhat DOT com
Subject: Re: dlsym discussion..
Message-ID: <20010603094842.E23205@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT sources DOT redhat DOT com
References: <016201c0ebfd$f8036840$0200a8c0 AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <016201c0ebfd$f8036840$0200a8c0@lifelesswks>; from robert.collins@itdomain.com.au on Sun, Jun 03, 2001 at 05:22:37PM +1000

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