[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problem with libtool relinking


> > Does anyone know if there is a better solution than a
> > build-conflicts?
> No, I use build-conflicts.  If anyone does have better ideas, I want
> to know too.  (:

I've had the same problem for vlc here [1] (real understanding of the
situation starts around comment #44). It took me ages to understand it:
it was injecting -L/dir before the libtool objects, which ended up
having -L/dir before -L$DESTDIR/dir when relinking with DESTDIR installs
and therefore (re)linking to the old libraries.
Having a quick look at regina by fetching the source package from the
debian archive, it seems it gives -L/dir in libfoo_la_LDFLAGS too:

$ grep all_libraries Makefile
all_libraries = -L/usr/lib64 -L/usr/qt/3/lib -L/usr/kde/3.5/lib

$ grep all_libraries kdeui/src/common/Makefile.am
libregina_kdecommon_la_LDFLAGS = -release @PACKAGE_VERSION@
$(all_libraries) \ 
libregina_kdecommon_la_LDFLAGS = -release @PACKAGE_VERSION@

So maybe putting the -L/-l linker args in LIBADD instead would fix the
problem. Another solution would be to make libtool ensure that
-L$(DESTDIR)/dir is always the first -L argument when relinking with
DESTDIR installs, but that's probably more difficult (and I'm not
sure if it's even possible). Moreover, I've never been sure what is
the right solution with libtool + automake: if LIBADD is really the only
sane way to append linking args (-L/-l) and is made for that or if
libtool should really ensure at any cost that -L$(DESTDIR)/dir comes
first when doing DESTDIR installs. That's probably worth asking on a
libtool mailing list.

I hope that helps.


[1] https://bugs.gentoo.org/show_bug.cgi?id=157746

Attachment: signature.asc
Description: PGP signature

Reply to: