This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.



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

On Feb  7, 2001, Mark Mitchell <> 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:

Alexandre Oliva <> 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/*,
> because this would introduce an unnecessary and possibly incorrect
> dependence of the library being created on /lib/*.
> 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/, 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]