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