Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3DE2E86D.6010303@ece.gatech.edu>
Date: Mon, 25 Nov 2002 22:20:13 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [Patch] skipping import libraries for performance reasons - direct auto-import of dll's
References: <00fe01c29480$b9453340$cd6407d5 AT BRAMSCHE> <20021126013800 DOT GA14011 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor 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.


Yep.  I think this is better handled as follows:

1) leave the basic libtool behavior alone; let it go ahead and build 
import libs (and try to link to them).

2) perhaps a new libtool switch could be created, that you would put in 
to Makefile.am:  libfoo_la_LDFLAGS = -no-undefined -fast-import

when -fast-import is specified, libtool (for cygwin target) "installs" 
the "import lib" into $libdir as a symlink:
   $libdir/libfoo.dll -> ../bin/cygfoo-X.dll
And $libdir/libfoo.la includes stuff like

dlname='cygcxxdll-0.dll'
library_names='libcxxdll.dll'
old_library='libcxxdll.a'

(the only difference from "current" (e.g. CVS HEAD) behavior is that 
right now, library_names='libcxxdll.dll.a')

I'm not sure how what the uninstalled file layout should be, or how the 
uninstalled .la file should refer to the dll/"implib" prior to 
installation (e.g. for linking further libs/exes in the same buildtree). 
  Probably even the link command should be different (don't specify 
-Wl,--out-implib=... at all; create the "implib" as a simple 'cp 
$dllfilename $implibname')

But all of this is way premature.  First, get the feature tested and 
merged into CVS.  Then into the [curr] binutils for cygwin.  Somewhere 
along the way, the runtime pseudo-reloc code goes into cygwin1.dll CVS 
or crt0.o CVS or wherever the heck it ends up.  And then wait for THAT 
to make it into the appropriate [curr] cygwin package.

And then we can worry about mucking with libtool.  It'll probably be 
post-libtool-1.5 at that time, but I doubt there will be another huge 
delay between libtool-1.5 and -1.5.1/2/3/..., as there was/is between 
libtool-1.3.x/1.4.x and 1.5release.  So don't worry about missing the 
1.5 window.


> However, as Chuck mentions that doesn't detract from the merits of the patch.
> I'm sure that it would still be very useful to a number of people.


pending testing, of course...

--Chuck


--
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/