Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3EB1EDFA.8070104@ece.gatech.edu>
Date: Fri, 02 May 2003 00:03:06 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joshua Kwan <joshk AT triplehelix DOT org>
CC: cygwin AT cygwin DOT com
Subject: Re: basename() implementation?
References: <20030501042813 DOT GA15911 AT triplehelix DOT org> <000d01c30f9e$7505a720$5f6886d9 AT ellixia> <20030501051325 DOT GA16157 AT triplehelix DOT org>
In-Reply-To: <20030501051325.GA16157@triplehelix.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Joshua Kwan wrote:

> On Thu, May 01, 2003 at 05:59:32AM +0100, Elfyn McBratney wrote:
> 
>>>BTW, I'm using libtool now so *supposedly* building shlibs are fixed.
> 
> 
> Nope.. :/
> 
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin 
> shared libraries
> 
> *sigh* This is just a pretty version of the problem I experienced 
> before. So... there is NO way to build _true_ shared libraries for 
> Cygwin that rely on code from the program that dlopens them? :/

That is correct.  Unless we (cygwin) write our own sharedlibrary loader 
and format, and stop using DLLs.  (I don't want or forsee this, because 
there are other ways around the problem)

(1) put the code that must be accessed by both the application and by 
the module into a separate DLL (of course, it too must be 
self-contained).  Then, link both the app and the module against this 
extra DLL.

(2) there is a new feature in CVS binutils, where .exe's can have export 
tables.  (The currently released cygwin binutils doesn't have this, yet, 
but it'll come, eventually).  Anyway, once you build the .exe with the 
export table (using a .def file or __declspec(dllexport) decorators), 
you then use dlltool to create an import library (.dll.a) **for the 
.exe**.  Then, you build the DLL and link against that import lib.

#2 is obviously more cutting edge, and I haven't tested it.  But it 
should work in principle.  There are some hooks in libtool-1.5 to 
support this mode, as well, but they haven't been tested (because it's 
dependent on a new binutils release).

--Chuck




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