[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PATCH: Support libtool -no-undefined under GNU/Linux (also *BSD, oth
From: |
Boehne, Robert |
Subject: |
RE: PATCH: Support libtool -no-undefined under GNU/Linux (also *BSD, other GNU ld systems) |
Date: |
Thu, 5 Jun 2003 16:55:45 -0500 |
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