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 -xustr=ascii_utf16_ush
different object sets in shared and static libs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've got a project where I'm building (by default) both shared and static libraries using libtool. However, the shared library also exports a java native interface, so I have a short list of .cpp files containing JNI code that should be part of the shared library, but has no business in the static library. Is there a way to specify additional objects (sources) for the shared library that will not be linked into the static library. I realize that linking these extra objects into the static library is more or less benign, as no one will ever call these functions from the static library, but it seems sad to carry the extra baggage in the static library. Thanks in advance, John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIUE3NdcgqmRY/OH8RAs0dAJ9/v1i+Kxiw0nj/5OaF2SDgcUdgFQCePLE2 6ugOBlup8uthmMoa6ku7VMY= =rq14 -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: different object sets in shared and static libs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Calcote wrote: > I've got a project where I'm building (by default) both shared and > static libraries using libtool. However, the shared library also exports > a java native interface, so I have a short list of .cpp files containing > JNI code that should be part of the shared library, but has no business > in the static library. > > Is there a way to specify additional objects (sources) for the shared > library that will not be linked into the static library. > > I realize that linking these extra objects into the static library is > more or less benign, as no one will ever call these functions from the > static library, but it seems sad to carry the extra baggage in the > static library. > > Thanks in advance, > John I forgot to add that I'm using Libtool from Automake. I guess it would be rather trivial to do what I want from a Makefile using libtool in my raw make rules. :) John -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIUE+5dcgqmRY/OH8RAhApAJwKDQGDErdvtTgB92TEKW5ljvgjTgCcC/yN dtLi9s61GejEPCKh955DKzU= =ZJ+v -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: different object sets in shared and static libs
John Calcote wrote: > Is there a way to specify additional objects (sources) for the shared > library that will not be linked into the static library. You could always wrap the entire contents of the file with "#ifdef PIC". The objects would still be in the static lib but they would be essentially empty files. I know, not the cleanest solution. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: different object sets in shared and static libs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, Brian Dessent wrote: > John Calcote wrote: > >> Is there a way to specify additional objects (sources) for the shared >> library that will not be linked into the static library. > > You could always wrap the entire contents of the file with "#ifdef > PIC". The objects would still be in the static lib but they would be > essentially empty files. I know, not the cleanest solution. > > Brian > H... :) John Actually, thanks for the response. That's not bad if it's the only thing possible. I always hate to hear that something can be done on Windows and not on Linux. But I also understand that it's the high level of abstraction in Automake that is causing the problem, not the inability to actually use different objects in different libraries. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIUFMAdcgqmRY/OH8RAn0IAJ9PzPrnjxfkpPfdOgAZJRnUDtlVuQCdEXcT rgZbIIDNsW6mS2qe02LbhVQ= =HBtb -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
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
