libtool devel package still dll crippled.

[Charles Wilson]

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