This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: PATCH: Support libtool -no-undefined under GNU/Linux (also *BSD, other GNU ld systems)
- From: "Boehne, Robert" <Robert dot Boehne at ricardo dot com>
- To: "Alexander Dupuy" <dupuy at sysd dot com>,<libtool-patches at gnu dot org>
- Cc: <mark at codesourcery dot com>,<gcc-patches at gcc dot gnu dot org>,<fjh at cs dot mu dot oz dot au>,<aoliva at redhat dot com>
- Date: Thu, 5 Jun 2003 16:55:45 -0500
- Subject: RE: PATCH: Support libtool -no-undefined under GNU/Linux (also *BSD, other GNU ld systems)
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:dupuy@sysd.com]
Sent: Thursday, June 05, 2003 3:56 PM
To: libtool-patches@gnu.org
Cc: mark@codesourcery.com; gcc-patches@gcc.gnu.org; fjh@cs.mu.oz.au;
aoliva@redhat.com
Subject: PATCH: Support libtool -no-undefined under GNU/Linux (also
*BSD, other GNU ld systems)
On Feb 7, 2001, Mark Mitchell <mark@codesourcery.com> 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 <aoliva@redhat.com> 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