Re: DESTDIR installs

[Guido Draheim]

Carl D. Roth wrote:
> > I had the same problem - libtool does not like destdir-install
> > with two libraries being interdependent. I had a look through
> > the sources how to pass it down to libtool - but the automake
> > generated install-line for the .la will now pass an extra
> > argument. Without help from automake, I assume it would be
> > too hard to do.
> >
> > Anyway, here's my solution - about the same trick but not
> > touching a global variable that might have defects on
> > subportions of the compilation:
> >
> > --- snip ---
> > %setup
> > # fixing relink problems during install
> > LDFLAGS="-L%buildroot%_libdir" \
> > CFLAGS="$RPM_OPT_FLAGS" \
> > sh configure --prefix=%{_prefix} --enable-shared
> >
> > %build
> > make
> >
> > %install
> > rm -rf $RPM_BUILD_ROOT
> > make install DESTDIR=%buildroot
> > --- snip ----
> >
> > There goes another question, however: the libtool-install
> > for the .la will know the target directory. In most cases,
> > the two interdependent libraries get installed in the same
> > target place (atleast for my problem it was/is the case).
> > May be auto-add an -L for the target directory implicitly?
>
>
> The desired behavior is for the flag to be added to the link-line
> when the library is installed/built by rpm, but we don't want
> the DESTDIR to be embedded in the .la file that is finally shipped...
> You would need to make sure that touching LDFLAGS won't cause the
> .la file to be altered...
>
> It's true that LIBRARY_PATH is gcc-specific, but I'm pretty sure it won't
> break other features of the build ;-)  Since the spec file is
> architecture-specific, I didn't see that as a problem.

Aaargh, thank you, I did miss this one - yes, it gets coded into the
.la infofile, what a pity :-(

| # The name of the static archive.
| old_library='libxmlpcre.a'

| # Libraries that this one depends upon.
| dependency_libs=' -L/my/rpm/tmp/xmlg-0.6.1/usr/lib /usr/lib/libxmlglib.la 
/usr/lib/libpcre.la /usr/lib/libglib-2.0.la'

> Another approach (usable in a patched libtool or in a wrapper script for
> the compiler) is to test for the DESTDIR prefix dynamically:
>
>   for each -L${DIR} switch in LDFLAGS
>     if $DESTDIR${DIR} is also a valid directory
>       prepend $DESTDIR${DIR} to LDFLAGS
>
> This way the .la files come out clean.

However, here we add "magic" that shouldn't be there. There should be some
explicit thing to be done. If we'd use this magic then it should be atleast
get configured right in with something like --destdir=$DESTDIR as to tell
./libtool *explicitly* that this prefix is temporary and about to be
relocated.


BTW, install-time linking has always been a problem - an rpm build has to
clean it up with some chrpath step on the library files.

Thinking it over again - changing a CC variable might be compiler specific,
what about using up another variable that is libtool specific and that
tells ./libtool to add these LIBTOOL_LDFLAGS to the relink-line? And
thereby not to put these extras into the .la? aaargh, phantasies... the
base problem is installtime relinking...