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

[Mark Wright]

On Sat, 14 Jun 2008 09:14:20 +0200
Ralf Wildenhues <address@hidden> wrote:

> Hello Mark,
> 
> * Mark Wright wrote on Fri, Jun 13, 2008 at 01:20:57PM CEST:
> > Ralf Wildenhues <address@hidden> 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

--