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

[Boehne, Robert]

Alexander,

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.

Thanks,

Robert

-----Original Message-----
From: Alexander Dupuy [mailto:address@hidden
Sent: Thursday, June 05, 2003 3:56 PM
To: address@hidden
Cc: address@hidden; address@hidden; address@hidden;
address@hidden
Subject: PATCH: Support libtool -no-undefined under GNU/Linux (also
*BSD, other GNU ld systems)


On Feb  7, 2001, Mark Mitchell <address@hidden> wrote:
> So, it would be really good if libtool would support -no-undefined
> usage on GNU/Linux.  If that means working around a GNU linker bug,
> isn't that the sort of thing libtool is supposed to do?

In the two year old message (thread) at:
  http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00390.html

Alexandre Oliva <address@hidden> replies:
> Yep.  I'm convinced.  I'll gladly accept patches that arrange for
> libtool to use, in decreasing order of preference:
>
> `${wl}--no-undefined', if running `$LD --no-undefined -shared -o
> conftest -lc' works, otherwise
>
> `${wl}--no-undefined ${wl}--allow-shlib-undefined', if running `$LD
> --no-undefined -shared -o conftest -lc' works, otherwise,
>
> empty, if everything else fails.
>
> I'd rather not explicitly link libraries against /lib/ld-linux.so.*,
> because this would introduce an unnecessary and possibly incorrect
> dependence of the library being created on /lib/ld-linux.so.*.
>
> If nobody beats me to it, I'll probably implement this myself some
> day.

While I can't believe that two years later, I might have beaten him to 
this, the recent libtool-1.5 release still didn't have any support for 
this useful functionality.  I had hacked something similar into 
libtool-1.4.something, but took this opportunity to do it more cleanly, 
per Alexandre's spec.

In my previous attempt, I had linked against /lib/ld-linux.so.2, but by 
actually passing --allow-shlib-undefined to the linker rather than the 
compiler, I found that wasn't necessary.

Anyhow, for anyone who (still) cares, attached are unidiffs to vanilla 
libtool 1.5 that implement libtool's -no-undefined option on GNU/Linux 
and other platforms that use GNU ld (e.g. *BSD variants, although I've 
only tested on Linux and FreeBSD 4.8).

I needed to add a -pthread flag so that on *BSD libtool could decide 
whether to add a dependency on -lc_r (to resolve undefined symbols) or 
just turn off the undefined symbol checking.  While this does defeat the 
checking in the common case, that seemed preferable to creating shared 
libraries/modules that broke threaded applications.  I figured that any 
application built with -pthread probably uses the extra functions in 
-lc_r, so adding a dependency there wasn't likely to break anything.

If there's a better solution for this (e.g. a way to add a shared 
library for resolving symbols without recording it in a NEEDED entry), 
I'd love to hear about it.

@alex