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
Date:	Tue, 26 Nov 2002 14:55:53 -0500
From:	Christopher Faylor <cgf AT redhat DOT com>
To:	cygwin AT cygwin DOT com, binutils AT sources DOT redhat DOT com
Subject:	Re: [Patch] skipping import libraries for performance reasons - direct auto-import of dll's
Message-ID:	<20021126195553.GB6605@redhat.com>
Reply-To:	cygwin AT cygwin DOT com, binutils AT sources DOT redhat DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com, binutils AT sources DOT redhat DOT com
References:	<20021126013800 DOT GA14011 AT redhat DOT com> <015101c2951d$a17fe960$cd6407d5 AT BRAMSCHE>
Mime-Version:	1.0
In-Reply-To:	<015101c2951d$a17fe960$cd6407d5@BRAMSCHE>
User-Agent:	Mutt/1.5.1i

On Tue, Nov 26, 2002 at 08:30:01AM +0100, Ralf Habacker wrote:
>cgf wrote:
>> On Mon, Nov 25, 2002 at 01:46:50PM +0100, Ralf Habacker wrote:
>>>3.  ld works more like the linux version.  There are only static
>>>archives and shared libraries which could be linked directly without
>>>the indirection of using import libraries.  This simplifies for example
>>>libtool handling.
>>
>>I don't see how.  If anything it would complicate libtool handling
>>since libtool would have to know about both import libraries and dlls.
>>You can't just give up on import libraries, if for no other reason than
>>some libraries (like cygwin's for instance) contain a combination of
>>import data and static data.
>
>This and perhaps other libraries may be an exception, but couldn't this
>splitted like linux does ?  If I remember right, they uses a standard
>lib like glibc, which may be a shared lib and some kind of startupcode
>in an objectfile (static), which may be different for executable or
>dll's or other kinds of output.  Why does cygwin uses a specific way ?

It doesn't matter what cygwin uses.  Cygwin is an example.  Changing
cygwin doesn't solve the issue for some other DLL.  Telling anyone that
they have to reorganize their projects to accommodate 'ld' is pretty
obviously the wrong thing to do.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -