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/
