Re: should libtool --relink expand lib*.la files before -L options?

[Mark Wright]

Hello Ralf,

Yes that helps, thanks.  Since it seemed hard to explain
and understand with the large program, I wrote a test case,
which I have attached, which reproduces the problem when run
on Solaris with an environment setup to use Sun Studio C++, with
enviroment variables like:

CXXCPP=/opt/SunStudio12/SUNWspro/bin/CC -E -Xs
CPP=/opt/SunStudio12/SUNWspro/bin/cc -E -Xs
CXX=/opt/SunStudio12/SUNWspro/bin/CC
CC=/opt/SunStudio12/SUNWspro/bin/cc

to tell autotools to use the Sun Studio C++ compiler.

Unfortunately the testcase does not reproduce the problem when
I try it with gcc 4.2.3 using the GNU linker.

One reason why it was a little difficult to reproduce is
the default behaviour when linking a shared library against
another shared library is to allow Unresolved symbols.
The problem of linking against the wrong library is only
seen in the testcase when the linker issues errors for
Unresolved symbols while linking the libtag_c.so shared
library, to get that behaviour, I set:

libtag_c_la_LDFLAGS = -no-undefined

in current/bindings/c/Makefile.am

To unpack the testcase in the current directory:

bzip2 -d libtool_pkg_sys.tar.bz2
tar xf libtool_pkg_sys.tar

to run it:

ksh -kx test_libtool_pkg_sys.ksh

So what it tries to show is:

(1) A old library is compiled and installed in $PWD/usr/lib.

(2) A new library is compiled and installed in a package
staging directory $PWD/pkgbuild/opt/foss/lib.

During the compile of the new library, LDFLAGS is
set to include libraries in:

$PWD/opt/foss/lib, which is like the /opt/foss/lib directory
where the KDE4 packages would be installed in the real system,
but in the test, this directory is empty.

$PWD/usr/lib, which is the test case analog of /usr/lib.

So the problem I am trying to show, if it occurs, is that
since LDFLAGS needs to include:

-L$PWD/opt/foss/lib -L$PWD/usr/lib

and an old version of the library was installed in step (1)
in -L$PWD/usr/lib, then when the new version of the library
is linked, the linker first finds the old library in L$PWD/usr/lib
because:

(a) Its in LDFLAGS, it needs to be.  Or in any case, in the real
system the old library is in /usr/lib and the linker looks in there
anyway.

*AND*

(2) libtool 2.2.4 placed the -L$PWD/pkgbuild/opt/foss/lib after
the LDFLAGS directories during the relink, here is the output
when I run the testcase on my Solaris 10 box with Sun Studio 12:

...
libtool: install: warning: relinking `libtag_c.la'
libtool: install:
(cd /h/goanna/2/eng/dev/autotools/t/current/bindings/c; /bin/bash 
/h/goanna/2/eng/dev/autotools/t/current/libtool
--tag CXX --mode=relink /opt/SunStudio12/SUNWspro/bin/CC -g
-no-undefined -L/h/goanna/2/eng/dev/autotools/t/opt/foss/lib
-L/h/goanna/2/eng/dev/autotools/t/usr/lib
-R/h/goanna/2/eng/dev/autotools/t/opt/foss/lib
-R/h/goanna/2/eng/dev/autotools/t/usr/lib -o libtag_c.la
-rpath /h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib call_a.lo
call_b.lo ../../taglib/libtag.la ) libtool:
relink: /opt/SunStudio12/SUNWspro/bin/CC -G -zdefs -hlibtag_c.so.0
-o .libs/libtag_c.so.0.0.0   .libs/call_a.o .libs/call_b.o
-R/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib
-R/h/goanna/2/eng/dev/autotools/t/opt/foss/lib
-R/h/goanna/2/eng/dev/autotools/t/usr/lib
-L/h/goanna/2/eng/dev/autotools/t/opt/foss/lib
-L/h/goanna/2/eng/dev/autotools/t/usr/lib
-L/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib -ltag
-library=Cstd -library=Crun -lc
Undefined                       first referenced
symbol                              in file
int B::func_b()                  .libs/call_b.o
ld: fatal: Symbol referencing errors. No output written
to .libs/libtag_c.so.0.0.0 libtool: install: error: relink
`libtag_c.la' with the above command before installing it make[3]: ***
[install-libLTLIBRARIES] Error 1 make[3]: Leaving directory
`/h/goanna/2/eng/dev/autotools/t/current/bindings/c' make[2]: ***
[install-am] Error 2 make[2]: Leaving directory
`/h/goanna/2/eng/dev/autotools/t/current/bindings/c' make[1]: ***
[install-recursive] Error 1 make[1]: Leaving directory
`/h/goanna/2/eng/dev/autotools/t/current/bindings' make: ***
[install-recursive] Error 1
+ cd ..
goanna% 

On Thu, 12 Jun 2008 08:07:16 +0200
Ralf Wildenhues <address@hidden> wrote:

> Hello Mark,
> 
> * Mark Wright wrote on Wed, Jun 11, 2008 at 04:17:11PM CEST:
> > 
> > In the libtool 2.2.4 relink command below,
> > the ../../taglib/libtag.la refers to a libtag.so library in the
> > build directory.  I'm, sorry about the zillion compiler options,
> > however I think only the -L options, the ../../taglib/libtag.la and
> > its corresponding
> > -L/var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib
> > -ltag options are relevant.
> > 
> > My hopefully simple question is: is there some way to persuade
> > libtool/autotools to look for the libtag.so shared library first in
> > /var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib/libtag.so.1.5.0?
> 
> I'm not sure I've understood this bug report completely, so I will
> give a couple of general remarks.
> 
> While link mode will try to use the uninstalled libraries throughout
> (so you don't pick up an old, previously installed one), relink mode
> will try to use the installed versions of the other just-built
> libraries.

Yes it does, however it finds an old library in LDFLAGS before the
installed one in:

-L/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib

so I was wondering if there was some option for libtool to place
the -L/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib before
the -L directories in LDFLAGS?

> That is done in order not to pick up paths to the build
> tree (which would, on some systems, end up hardcoded in the resulting
> binary).  Consequently, it needs to be ensured that "make install"
> installs uninstalled libraries in the order of lowest-level first,
> ones depending on those later.
> 
> Now, if the order in which those links are done on your command line
> matters, then it looks to me like
> - either that install order is not right,
> - or there is some other library that links to libtag indirectly,
>   IOW, some library dependency is not specified correctly in the link,
> - or there is some completely independent library in that -L path

Yes, and old one, I wish it was not there, but it is, I can't remove it.

>   that you'd like to appear early, that is needed but wasn't properly
>   taken care of.
> 
> Does this help?
> 
> Cheers,
> Ralf

Yes it does, thanks.  Would be great if libtool had some option to
place the -L/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib in
front of the LDFLAGS -L options.

Thanks very much, Mark

--

libtool_pkg_sys.tar.bz2
Description: application/bzip