[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [master] allow_undefined_flag=unsupported breaks runpath-in-lalib.at
Re: [master] allow_undefined_flag=unsupported breaks runpath-in-lalib.at (28)
Sun, 23 Nov 2008 14:24:18 +0100
addressing your mail a bit reordered, the easier item first:
* Michael Haubenwallner wrote on Wed, Nov 19, 2008 at 04:50:56PM CET:
> Also this situation is broken (reusing input from runpath-in-lalib.at),
> even with default allow_undefined_flag="":
> * liba.la is created with -static (as static only)
> * libb.la is created (as both shared and static)
> but dependency_libs does not contain liba.la
> * m is created with -static
> resulting in a() being undefined.
AFAICS this will try to put the code from liba.a(a.o) into the shared
library libb.so. This will generate a relocation error on most
architectures (pretty much all except x86), because you cannot put
non-PIC code into shared libraries.
So the answer to this second scenario is: don't do that if it hurts.
Don't let shared libraries depend on static libraries.
> seems that libtool does not record .la libs into dependency_libs when:
> * shared libs initially should be created
> * '-no-undefined' is not passed
> * but allow_undefined_flag="unsupported"
> As a result,
> * this warning is printed (fine):
> "undefined symbols not allowed in $host shared libraries"
> * only the static library is created (fine)
> but: dependency_libs does not contain the dependent libraries.
> This can easily be tried on Linux with first setting
> allow_undefined_flag=unsupported and then running testsuite 28:
> Effect is that libb.la (static only) does not depend on liba.la (static
> only too, might not matter), so the 'm' executable fails to link.
> This bites me on AIX when I explicitly do not want runtime linking, so I
> (want to) have allow_undefined_flag=unsupported.
Hmm. I wonder whether the intended action in this case was to add a.o
to libb.a, or to list liba.la in dependency_libs of libb.la.
Thanks for the report.