Re: [master] allow_undefined_flag=unsupported breaks runpath-in-lalib.at (28)

[Ralf Wildenhues]

Hello Michael,

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.

Cheers,
Ralf