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 <[EMAIL PROTECTED]> 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
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool