This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: libtool devel package still dll crippled.
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Ralf Habacker <Ralf dot Habacker at freenet dot de>
- Cc: Cygwin-Apps <cygwin-apps at cygwin dot com>
- Date: Sun, 14 Apr 2002 13:52:52 -0400
- Subject: Re: libtool devel package still dll crippled.
- References: <000301c1e3b8$2164db30$ea6007d5@BRAMSCHE>
Ralf Habacker wrote:
>>must be some way to prevent ld outputting the imported
>>
> symbols as
>
>>well as the exported symbols...
>>
>
> I'm using a special patched ld (based on the recent official
> ld) which rejects exporting of all imported libs with a one
> line patch
>
> binutils/ld/pe-dll.c:234
> /* Do not specify library suffix explicitly, to allow for
> dllized versions. *
> static autofilter_entry_type autofilter_liblist[] =
> {
> { "libgcc.", 7 },
> { "libstdc++.", 10 },
> { "libmingw32.", 11 },
> +// RH: workaround to allow using static libs in multiple
> dlls
> + { ".a", 2 },
> { NULL, 0 }
> };
I really think this is a mistake. What if I want to build a shared
library using libtool, and it is composed of a number of object files
but also some convenience libs? And those convenience libs contains
symbols that I want to export?
Blindly refusing to export the symbols from anything that ends in .a is
a mistake, IMO. (I could be convinced that re-exporting symbols
obtained from a .dll.a is always bad, and should be screened out using
the brute-force, non-overrideable method in the patch above, but not .a)
--Chuck