On Tue, Oct 19, 2004 at 08:49:30PM +0100, Roger Leigh wrote: > Many Makefile.ams use logic like this: > > if PLATFORM_WIN32 > no_undefined = -no-undefined > endif > > lib_LTLIBRARIES = libfoo > libfoo_LDFLAGS = ... $(no_undefined) > > > This makes -no-undefined only get used when building DLLs on a Win32 > platform. However, if this were specified directly: > > foo_LDFLAGS = -no-undefined > > does this do anything on other platforms where it's not required? > > I tested both on GNU/Linux, and while I couldn't see any functional > difference between the two libs, the binaries were not identical. It > does concern me that it had /some/ effect, especially since it isn't > obvious what exactly it actually did.
I would have expected identical binaries on GNU/Linux. Indeed, binaries built with and without -no-undefined should be identical on _all_ platforms; without -no-undefined, libtool simply does not build a shared library on platforms that do not allow undefined symbols in shared libraries. I'll look at crafting a test case around the equivalence of -no-undefined and regular binaries. I appreciate the report. > If there wasn't some (perhaps historical) reason for the former usage, > it seems a little odd to use platform-specific stuff in a tool that's > supposed to be platform-independent. I see no reason to use snippets of that nature any longer. Besides, as Bob noted, W32 is not the only platform that does not allow undefined symbols in shared libraries. > Please could anyone clarify exactly how -no-undefined should be used > when building shared libraries for a package that should build on all > platforms. If your shared library resolves all symbol references at link time, use -no-undefined unconditionally. If you use -no-undefined with success on Windows, it should be safe to also use it everywhere else. I suspect very few libraries cannot, by design, resolve all symbols at link time. It is, however, easy to craft a link line that omits dependencies, thereby preventing the resolution of all symbols. For example, if libfoo depends on libfoo_dep, this might work on GNU/Linux, libtool --mode=link $(CC) -o libfoo.la foo.lo bar.lo but you would need this to work on both GNU/Linux and Windows: libtool --mode=link $(CC) -o libfoo.la -lfoo_dep foo.lo bar.lo That is probably why -no-undefined is not a default: a build setup that works on a system allowing undefined symbols in libraries may need modifications to also work on systems that do not allow undefined symbols, so -no-undefined indicates that you have made any such changes. _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool