Re: Portability of -no-undefined

[Noah Misch]

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.