From: Ralf W. <Ral...@gm...> - 2006-01-26 12:39:59
|
Hi Tim, Hope to actually add some content to this thread now.. * Tim Teulings wrote on Tue, Jan 24, 2006 at 10:32:19PM CET: > > > 1) Did you add -no-undefined to the link line? If no, please do so. > > It this a "Windows-only" or should this be added for building > libtool-based shared-libraries on all systems? -no-undefined carries around some historic ballast, unfortunately. 1) On some systems, notably win32 ones, it is (or was at one time) not possible to create libraries with unresolved symbols (or libtool data assumes so). 2) On some (other) systems, there exist flags to provoke linker failure when not all symbols are resolved, again, when creating a shared library. 3) On a subset of the systems in (2), the flag doesn't or can't work in all situations.[1] For example, because explicit linking against the C standard library or a C++ standard library is broken, or because of numerous other possible deficiencies, that may or may not be controllable by the package author. 4) At some point in Libtool history, it was deemed that the default setting for creating libraries should be to allow undefined symbols, instead of "to allow undefined symbols if the host platform supports it".[2] 5) Consequence: without `-no-undefined', libtool will not create shared libraries at all on win32 systems at the moment. Common practice in packages is to either use `-no-undefined' unconditionally, or, when that turns out not to work everywhere, to use `-no-undefined' on $host_os systems matching `cygwin*' or `mingw*'.[3] In case of doubt, the latter is pretty safe. Hope that clarifies it a bit. And yes, it would probably be good to have a flag -no-undefined-if-system-needs-it Cheers, Ralf [1] The flag is still very useful for many packages, so not using it would remove useful functionality for a lot of people. [2] There is actually an argument to support this: what if the system evolves and allows undefined symbols at some point in the future? Should the libtool default change then? How would people know? [3] libtool.m4 disallows also on `beos*', but a comment states that this may not actually be true in every case. |