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] INIT 0x4f34 [11] FINI 0x5004 [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 \ -L/opt/foss/lib -L/usr/lib -R/opt/foss/lib:/usr/lib \ lots_of_options_omitted 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 lots_of_libraries_and_options_omitted 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% So I thought this might be confusing to other developers if they hit this issue. I wondered if libtool should have an option to link it like: 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/var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib -L/opt/foss/lib -L/usr/lib \ -ltag lots_of_libraries_and_options_omitted So it would give preference to the libraries it just built in the same package that it is now installing, rather than other libraries that might be found in the -L options in LDFLAGS. (Although if libtool was changed for this, I would wonder if this should be the default behaviour, and if there should be a libtool flag to get the current behaviour). The testcase I wrote was just to reproduce this issue. Of course I have a simple workaround now that I understand it. I just simply add the -L/var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib option that libtool added at the front of my LDFLAGS before doing the configure. Thanks very much, Mark -- _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
