Mail Archives: cygwin/2002/11/25/22:21:41
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/
- Raw text -