This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] skipping import libraries for performance reasons - direct auto-import of dll's


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]