Re: should libtool --relink expand lib*.la files before -L options?
On Sat, 14 Jun 2008 09:14:20 +0200 Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Mark, * Mark Wright wrote on Fri, Jun 13, 2008 at 01:20:57PM CEST: Ralf Wildenhues [EMAIL PROTECTED] wrote: Generally, if you want to have several versions of some library at the same time, put them in distinct $prefix'es, apart from other libraries. That helps to minimize such conflicts. One the KDE4 Solaris project we have to somehow copy with incompatible libraries installed in /usr by the JDS Gnome project. Unfortunately we do not have that luxury. Incompatible libs in /usr shouldn't be a problem: there's hardly any need to place -L/usr/lib anywhere, much less near the beginning of a link command line. If libtool causes that, that sounds like a bug. Hello Ralf, I set: LDFLAGS='-L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib' But of course none of us get paid to work on KDE4 or libtool. Well, what I was talking about wasn't a libtool limitation as such. Imagine this situation: you have /debug/liba /debug/libb /opt/liba /opt/libb There is no way using only -L/-l flags that you can allow the user to mix and match a choice where one optimized library is used and one debug variant. It just doesn't work that way unless you resort to symlinking or using /path/libfoo.so or similar directly in a link line. The latter however creates nasty DT_NEEDED entries on some systems (including Solaris, iff the library happens to not have a proper soname). We like those DT_NEEDED entries, and we hard code the runpath in the library using -R/opt/foss/lib:/usr/lib . This is how the library looks after I worked around the libtool linking to the wrong libraries by adding the another -L option for it to find: /h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib/libtag.so instead of: /usr/lib/libtag.so by setting LDFLAGS like: export LDFLAGS=-L/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib $LDFLAGS goanna% dump -Lv /opt/foss/lib/libtag_c.so /opt/foss/lib/libtag_c.so: DYNAMIC SECTION INFORMATION .dynamic: [INDEX] Tag Value [1] NEEDED libtag.so.1 [2] NEEDED libz.so.1 [3] NEEDED libCrun.so.1 [4] NEEDED libstdcxx.so.4 [5] NEEDED libc.so.1 [6] NEEDED libm.so.2 [7] NEEDED libdl.so.1 [8] NEEDED libpthread.so.1 [9] NEEDED librt.so.1 [10]INIT0x4f34 [11]FINI0x5004 [12]SONAME libtag_c.so.0 [13]RUNPATH /opt/foss/lib:/opt/foss/lib:/usr/lib:/opt/SunStudio12/SUNWspro/lib/rw7:/opt/SunStudio12/SUNWspro/lib/sse2:/opt/SunStudio12/SUNWspro/lib:/opt/SUNWspro/lib/sse2:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib [14]RPATH /opt/foss/lib:/opt/foss/lib:/usr/lib:/opt/SunStudio12/SUNWspro/lib/rw7:/opt/SunStudio12/SUNWspro/lib/sse2:/opt/SunStudio12/SUNWspro/lib:/opt/SUNWspro/lib/sse2:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib ... goanna% For the libtool relink issue above and discussed earlier, on some projects it might help avoid other developers hitting the relink problem if libtool had an option to look for libraries in the build directories first. Hrmph, it may be that I'm still misunderstanding you. Your examples are complex and I'm not totally sure I'm hitting the nail on the head here. But really I see two viable installation strategies that work portably: either one has one prefix per package, enabling one to mix and match quite freely. Or one has few prefixes which are somehow themed (debug vs optimized; or old vs. new vs. newest) from which one either picks just one directory, or there is a total ordering by which one can go. Mixing and matching from the latter just won't work. IOW, I still fail to see how this is a bug in libtool rather than a problem inherent in your setups. If this is due to my continued misunderstanding, then please help me see why this I'm wrong. Thanks, Ralf I'm sorry about all the crazy compiler optimization and linker options. Here I have omitted most of the compiler and linker options, just leaving the ones I think are relevant. So this is with: LDFLAGS='-L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib' So what I was wondering might be a libtool issue is: In the command line passed to CC to do the link, libtool has added the -L option to find the libtag.so library that was just installed: -L/var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib after my LDFLAGS library search options: -L/opt/foss/lib -L/usr/lib so it happens to find an old libtag.so in /usr/lib, which then fails to link as we use an option to not allow unresolved symbols when linking libraries (we really want to link to the correct libraries): goanna% /bin/bash /h/goanna/2/os_5.10/cbe/BUILD/FOSStaglib-1.5.0/i386/TAGLIB/1.5.0/libtool \ --tag CXX --mode=relink /opt/SunStudio12/SUNWspro/bin/CC lots_of_options_omitted \
Re: should libtool --relink expand lib*.la files before -L options?
Hello Mark, * Mark Wright wrote on Fri, Jun 13, 2008 at 01:20:57PM CEST: Ralf Wildenhues [EMAIL PROTECTED] wrote: Generally, if you want to have several versions of some library at the same time, put them in distinct $prefix'es, apart from other libraries. That helps to minimize such conflicts. One the KDE4 Solaris project we have to somehow copy with incompatible libraries installed in /usr by the JDS Gnome project. Unfortunately we do not have that luxury. Incompatible libs in /usr shouldn't be a problem: there's hardly any need to place -L/usr/lib anywhere, much less near the beginning of a link command line. If libtool causes that, that sounds like a bug. But of course none of us get paid to work on KDE4 or libtool. Well, what I was talking about wasn't a libtool limitation as such. Imagine this situation: you have /debug/liba /debug/libb /opt/liba /opt/libb There is no way using only -L/-l flags that you can allow the user to mix and match a choice where one optimized library is used and one debug variant. It just doesn't work that way unless you resort to symlinking or using /path/libfoo.so or similar directly in a link line. The latter however creates nasty DT_NEEDED entries on some systems (including Solaris, iff the library happens to not have a proper soname). For the libtool relink issue above and discussed earlier, on some projects it might help avoid other developers hitting the relink problem if libtool had an option to look for libraries in the build directories first. Hrmph, it may be that I'm still misunderstanding you. Your examples are complex and I'm not totally sure I'm hitting the nail on the head here. But really I see two viable installation strategies that work portably: either one has one prefix per package, enabling one to mix and match quite freely. Or one has few prefixes which are somehow themed (debug vs optimized; or old vs. new vs. newest) from which one either picks just one directory, or there is a total ordering by which one can go. Mixing and matching from the latter just won't work. IOW, I still fail to see how this is a bug in libtool rather than a problem inherent in your setups. If this is due to my continued misunderstanding, then please help me see why this I'm wrong. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: should libtool --relink expand lib*.la files before -L options?
On Thu, 12 Jun 2008 23:32:29 +0200 Ralf Wildenhues [EMAIL PROTECTED] wrote: * Mark Wright wrote on Thu, Jun 12, 2008 at 06:06:58PM CEST: Ralf Wildenhues [EMAIL PROTECTED] wrote: 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 That's the sort of conflict that is just impossible to resolve. For your specific case, the path to the newly installed library should go early, for other users it shouldn't (because they have other, unrelated libraries in both the newly installed path and some other path listed early). Sorry, you can't have that sort of flexibility portably. Hello Ralf, OK, thanks. I used the workaround of placing the newly installed library location first in LDFLAGS, something like: export LDFLAGS=-L/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib $LDFLAGS If you need other libraries from that path where the old, unwanted one lives, make symlinks to them in some new directory. That would probably help in some other people's situations, but I don't have that luxury as we are trying to create a build environment so that other developers can build KDE4. For this particular library, it relinked OK with the package installation directory at the front of the LDFLAGS. On Solaris the runpath is determined by the -R options (like GNU ld -runpath). So with the real library the runpath does not contain the directory that I added at the front of the LDFLAGS: goanna% dump -Lv /opt/foss/lib/libtag_c.so | grep RUNPATH [13] RUNPATH /opt/foss/lib:/opt/foss/lib:/usr/lib:/opt/SunStudio12/SUNWspro/lib/rw7:/opt/SunStudio12/SUNWspro/lib/sse2:/opt/SunStudio12/SUNWspro/lib:/opt/SUNWspro/lib/sse2:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib goanna% So it finds the other libraries OK without creating symlinks. Generally, if you want to have several versions of some library at the same time, put them in distinct $prefix'es, apart from other libraries. That helps to minimize such conflicts. Cheers, Ralf One the KDE4 Solaris project we have to somehow copy with incompatible libraries installed in /usr by the JDS Gnome project. Unfortunately we do not have that luxury. But of course none of us get paid to work on KDE4 or libtool. For the libtool relink issue above and discussed earlier, on some projects it might help avoid other developers hitting the relink problem if libtool had an option to look for libraries in the build directories first. But I guess that would be hard to code in libtool, I would not know where to start. The workaround seems easy after we understand the problem. However here is a similar failure, this time during a link: pkgbuild: /bin/bash ../libtool --tag=CC --mode=link /opt/SunStudio12/SUNWspro/bin/cc -xc99=%all -errshort=full -errfmt=error -errwarn=%none -g -xdebugformat=stabs -xcsi -xustr=ascii_utf16_ushort -xalias_level=std -features=extinl -xF=%none -xbuiltin=%all -xinline=%auto -xprefetch=auto -xprefetch_auto_type=indirect_array_access -xprefetch_level=3 -xthreadvar=%all -z combreloc -z redlocsym -z nodefaultlib -z ignore -z now -z rescan -z absexec -xldscope=symbolic -xlibmil -xipo=0 -xO3 -g -xipo=0 -xO3 -xregs=no%frameptr -xjobs=2 -KPIC -xrestrict=%all -xtarget=pentium4 -m32 -xarch=sse2 -xchip=pentium4 -xcache=8/64/4:256/128/8 -L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib -lc -lm -ldl -lpthread -lposix4 -lrt -mt -D_REENTRANT -D__EXTENSIONS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS -DSOLARIS10 -DNDEBUG -DNO_DEBUG -D_UNICODE -DUNICODE -D_XOPEN_SOURCE=600 -D_XPG6 -D_POSIX_C_SOURCE=200112L -D__XOPEN_OR_POSIX -D_STRICT_STDC -D_STRICT_STDC__ -D_STDC_C99 -D_ISOC99_SOURCE -I/opt/foss/include -L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib -z combreloc -z redlocsym -z nodefaultlib -z ignore -z now -z rescan -z absexec -xldscope=symbolic -xlibmil -xipo=0 -xO3 -g -xtarget=pentium4 -m32 -xarch=sse2 -xchip=pentium4 -xcache=8/64/4:256/128/8 -lc -lm -ldl -lpthread -lposix4 -lrt -mt -o cd-info cd-info.o cddb.o util.o getopt.o getopt1.o ../lib/iso9660/libiso9660.la ../lib/driver/libcdio.la -L/opt/foss/lib -lvcdinfo -liso9660 -lcdio -lsocket -lncursesw -lnsl -lm -liconv -liconv -lsocket -lncursesw -ltinfow -lnsl -lm pkgbuild: libtool: link: /opt/SunStudio12/SUNWspro/bin/cc -xc99=%all -errshort=full -errfmt=error -errwarn=%none -g -xdebugformat=stabs -xcsi -xustr=ascii_utf16_ushort -xalias_level=std -features=extinl -xF=%none -xbuiltin=%all -xinline=%auto -xprefetch=auto -xprefetch_auto_type=indirect_array_access -xprefetch_level=3 -xthreadvar=%all -z combreloc -z redlocsym -z nodefaultlib -z ignore -z now -z rescan -z absexec -xldscope=symbolic
Re: should libtool --relink expand lib*.la files before -L options?
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. 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 that you'd like to appear early, that is needed but wasn't properly taken care of. Does this help? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: should libtool --relink expand lib*.la files before -L options?
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
Re: should libtool --relink expand lib*.la files before -L options?
* Mark Wright wrote on Thu, Jun 12, 2008 at 06:06:58PM CEST: Ralf Wildenhues [EMAIL PROTECTED] wrote: 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 That's the sort of conflict that is just impossible to resolve. For your specific case, the path to the newly installed library should go early, for other users it shouldn't (because they have other, unrelated libraries in both the newly installed path and some other path listed early). Sorry, you can't have that sort of flexibility portably. If you need other libraries from that path where the old, unwanted one lives, make symlinks to them in some new directory. Generally, if you want to have several versions of some library at the same time, put them in distinct $prefix'es, apart from other libraries. That helps to minimize such conflicts. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
should libtool --relink expand lib*.la files before -L options?
Hi, 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? As in, I was wondering if libtool should expand the: ../../taglib/libtag.la into: -L/var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib -ltag before the other -L options? As instead what happens is it finds an old, incompatible one in /usr/lib/libtag.so.1.4.0, which causes the unresolved symbol errors. In the Makefile.am it just does: libtag_c_la_LIBADD = ../../taglib/libtag.la This is Solaris 10u5, Sun Studio 12, libtool 2.2.4, KDE 4 project. So this is libtool 2.2.4 finding the wrong library in /usr/lib/libtag.so.1.4.0: goanna% /bin/bash /h/goanna/2/os_5.10/cbe/BUILD/FOSStaglib-1.5.0/i386/TAGLIB/1.5.0/libtool --tag CXX --mode=relink /opt/SunStudio12/SUNWspro/bin/CC -D_REENTRANT -D__EXTENSIONS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS -DSOLARIS10 -DNDEBUG -DNO_DEBUG -D_UNICODE -DUNICODE -D_RWSTD_REENTRANT -D_XOPEN_SOURCE=500 -D_XPG5 -I/opt/foss/include/ansi -I/opt/foss/include -I/opt/foss/include/ansi -library=no%Cstd -features=anachronisms,except,rtti,export,extensions,nestedaccess,tmplife,tmplrefstatic -instances=global -template=geninlinefuncs -g0 -xdebugformat=stabs -xlang=c99 -xustr=ascii_utf16_ushort -Qoption ccfe -features=gcc -Qoption ccfe -features=zla -Qoption ccfe ++boolflag:sunwcch=false -xF=%none -xbuiltin=%all -xinline=%auto -xprefetch=auto -xprefetch_auto_type=indirect_array_access -xprefetch_level=3 -xalias_level=compatible -KPIC -xipo=0 -xO3 -xregs=no%frameptr -xjobs=2 -xrestrict=%all -xthreadvar=%all -z combreloc -z redlocsym -z nodefaultlib -z ignore -z now -z rescan -z absexec -xldscope=symbolic -xlibmil -xipo=0 -xO3 -g -xtarget=pentium4 -m32 -xarch=sse2 -xchip=pentium4 -xcache=8/64/4:256/128/8 -lc -lm -ldl -lpthread -lposix4 -lrt -mt -L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib -Y P,/opt/foss/lib:/usr/lib -i -L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib -Bdynamic -lc -lm -lCrun -lstdcxx -Y P,/opt/foss/lib:/usr/lib -i -L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib -Bdynamic -lc -lm -lCrun -lstdcxx -xtarget=pentium4 -m32 -xarch=sse2 -xchip=pentium4 -xcache=8/64/4:256/128/8 -xipo=0 -xO3 -no-undefined -version-info 0:0 -L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib -z combreloc -z redlocsym -z nodefaultlib -z ignore -z now -z rescan -z absexec -xldscope=symbolic -xlibmil -xipo=0 -xO3 -g -xtarget=pentium4 -m32 -xarch=sse2 -xchip=pentium4 -xcache=8/64/4:256/128/8 -lc -lm -ldl -lpthread -lposix4 -lrt -mt -o libtag_c.la -rpath /opt/foss/lib tag_c.lo ../../taglib/libtag.la -inst-prefix-dir /var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build libtool: relink: /opt/SunStudio12/SUNWspro/bin/CC -G -zdefs -hlibtag_c.so.0 -o .libs/libtag_c.so.0.0.0 .libs/tag_c.o -R/opt/foss/lib -R/opt/foss/lib:/usr/lib -L/opt/foss/lib -L/usr/lib -L/var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib -ltag -lz -library=no%Cstd -lCrun -lstdcxx -lc -lm -ldl -lpthread -lposix4 -lrt -lc -xtarget=pentium4 -m32 -xarch=sse2 -mt -xtarget=pentium4 -m32 -xarch=sse2 -xtarget=pentium4 -m32 -xarch=sse2 -mt -mt Undefined first referenced symbol in file TagLib::TrueAudio::File::File(const char*,bool,TagLib::AudioProperties::ReadStyle) .libs/tag_c.o TagLib::Ogg::Speex::File::File(const char*,bool,TagLib::AudioProperties::ReadStyle) .libs/tag_c.o TagLib::WavPack::File::File(const char*,bool,TagLib::AudioProperties::ReadStyle) .libs/tag_c.o TagLib::Ogg::FLAC::File::File(const char*,bool,TagLib::AudioProperties::ReadStyle) .libs/tag_c.o ld: fatal: Symbol referencing errors. No output written to .libs/libtag_c.so.0.0.0 goanna% And this is how I would like libtool to link it, is there some option for libtool 2.2.4 to move the: -L/var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib -ltag first, before the -L options, like the following link command that works: goanna% /opt/SunStudio12/SUNWspro/bin/CC -D_REENTRANT -D__EXTENSIONS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS -DSOLARIS10 -DNDEBUG -DNO_DEBUG -D_UNICODE -DUNICODE -D_RWSTD_REENTRANT -D_XOPEN_SOURCE=500 -D_XPG5 -I/opt/foss/include/ansi -I/opt/foss/include -I/opt/foss/include/ansi -library=no%Cstd -features=anachronisms,except,rtti,export,extensions,nestedaccess,tmplife,tmplrefstatic -instances=global -template=geninlinefuncs -g0 -xdebugformat=stabs -xlang=c99
