bug-libtool
[Top][All Lists]
Advanced

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

Re: cross-build problem


From: Ralf Wildenhues
Subject: Re: cross-build problem
Date: Sun, 4 Nov 2007 22:16:00 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

* Thomas Koeller wrote on Sun, Nov 04, 2007 at 08:28:41PM CET:
> On Sonntag, 4. November 2007, Ralf Wildenhues wrote:
> > * Thomas Koeller wrote on Sun, Nov 04, 2007 at 01:48:43PM CET:
> > >
> > > Because I am cross-building, my CFLAGS and LDFLAGS variables contain
> > > the --sysroot switch. When 'libtool --mode=install' is invoked, the
> > > following happens:
> >
> > Instead of passing --sysroot, you can try passing -Wc,--sysroot=... to
> > get the flag through libtool.  It may work for you, but it will not
> > solve the more fundamental underlying issue:  Libtool does not recognize
> > that you are using a sysroot, and it will either search for dependent
> > installed libraries in the wrong locations or put the wrong (sysroot-
> > prefixed) deplib paths into the .la file that you are creating.
> 
> Why would libtool need to be aware of a sysroot being used?

Because it actually searches the search paths for dependent libraries.
It adds run path entried for deplibs that happen to be libtool libraries
but live in locations the runtime linker will not search by default.

Simply knowing whether /foo/usr/lib is such a location, or whether it is
a sysroot prefix of /foo plus a default-searched location /usr/lib,
cannot be known otherwise.  And with /foo/nonstandard/lib, it certainly
should not add a run path entry for /foo/nonstandard/lib instead of
/nonstandard/lib, because that path will not be valid once all libraries
live in their final location.

> The linker takes care of that.

Actually, if a library you link against has indirect deplibs that happen
to live in locations the runtime linker will not search for by default,
and it has run path entries for the directories, then you need for
example -rpath-link to override that.  Now, that is something that would
be nifty if libtool could make use of.  Of course that's pretty
unportable as it's restricted to GNU/Linux.

> All that libtool is supposed to do is to pass my
> LDFLAGS to the linker unmodified. It does so for all the 'libtool --mode=link'
> commands executed during the build, and all these commands succeed. If
> it did the same for '--mode=relink', that command would succeed just as
> well, as I could prove by editing the command line accordingly.

Libtool tries to not pass through link flags that it does not
understand, and whose semantics will break libtool functionality.  This
is intentional, albeit sometimes a bit hard on the user.  Actually, it's
even the other way round: libtool only explicitly allows through a set
of flags that it does understand.  For the rest (those that it swallows
but which are actually safe to pass), please write a bug report.
Thanks.  --sysroot is not among them.  By using -Wc, you are given a
workaround that allows you to shoot yourself in the foot.

> > This is a limitation in libtool that has not been solved yet.  One way
> > to work around it is to use -Wc, as above, and afterwards rewrite
> > dependency_libs in the .la file you just created.
> 
> To me this does not look like a fundamental problem, more like a
> simple coding error in libtool.

Not really.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]