Re: PATCH: Support libtool -no-undefined under GNU/Linux (also *BSD,other GNU ld systems)

[Alexander Dupuy <dupuy at sysd dot com>]

Boehne, Robert wrote:
> So you're trying to change how -no-undefined works, right?
> I see some pthread related stuff in the patch too, so I
> don't think this is what you wanted.  I'd like to have you
> explain what the patch should do as well.  We could all re-read
> the thread and each of us might come up with a different understanding
> of what was decided.  I'm not that clear on what the intent is yet.

Currently, on Linux and other systems using GNU ld, -no-undefined has no 
effect when building shared libraries or modules.  On Solaris with the 
Sun linker (and maybe also with GNU ld), it causes link failure if there 
are symbols that cannot be resolved.  On other systems (Windows, AIX, 
others?), unresolvable symbols are always errors when building shared 
libraries or modules.

The intent of the patch is to give -no-undefined the same semantics on 
Linux and other systems using GNU ld, namely, that a link will fail if 
there are symbols that cannot be resolved given the dependencies 
specified in the link command.

This will break some applications that use -no-undefined, but those 
applications already have portability problems, since those semantics 
are required on other platforms.  There is also an easy workaround, 
since omitting -no-undefined allows such applications to continue to 
build on those platforms where undefined symbol references are allowed.

The pthread related stuff in the patch is intentional, and is necessary 
for -no-undefined to be useful on FreeBSD/OpenBSD systems.  *BSD 
pthreads uses a reentrant version of the C library, -lc_r, which is 
incompatible with -lc, and any program that ends up with dependencies on 
both -lc and -lc_r will not run correctly.  For this reason, libtool 
goes to some lengths to avoid creating dependencies on either -lc or 
-lc_r.  However, by omitting this dependency, any use of standard C 
library functions (e.g. strlen, open, etc.) will result in undefined 
symbols, which makes -no-undefined pretty worthless.  (The autoconf 
AC_LIBTOOL_LINKER_OPTION macro used to test for GNU ld --no-undefined 
support doesn't use any functions at all, so it succeeds with 
-Wl,--no-undefined regardless of presence of -lc or -lc_r).

If the -pthread compiler/linker option is not given, my patched libtool 
will simply disable -no-undefined checking, restoring the current 
behavior.  This prevents a dependency on -lc that could break use of the 
generated shared library or module in a threaded program.

If the -pthread compiler/linker option *is* given, my patched libtool 
will create a dependency on -lc_r if and only if the -no-undefined 
option is also given.  By keeping this dependency, -no-undefined 
checking will not fail due to references to standard C library (or 
pthreads) symbols defined in -lc_r.  While this may cause the resulting 
shared library or module to break if used in a non-threaded application, 
it is very unlikely that anything built with -pthread doesn't use 
pthread functions (which are not defined in -lc, and which would cause 
runtime failure anyhow).

I chose the -pthread option to control this, as it is only used for 
Linux and *BSD threads (according to the autoconf extension ACX_PTHREAD, 
see http://www.gnu.org/software/ac-archive/htmldoc/acx_pthread.html) and 
there are other ways to enable threading for Linux (e.g. -lpthread).

Applications that want to create thread-safe code for *BSD that doesn't 
actively use thread constructs can still use -D_THREAD_SAFE, which on 
*BSD will result in disabled -no-undefined.  (I was going to suggest the 
more portable libtool -thread-safe option, but that has no effect since 
(_LT_AC_TAGVAR(thread_safe_flag_spec, $1) is never set).

@alex
--
mailto:dupuy@sysd.com