Re: --with-sysroot conflicts in binutils and gcc

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sat, Oct 23, 2010 at 10:27:19AM CEST:
> On 10/23/2010 10:01 AM, Ralf Wildenhues wrote:
> >* Paolo Bonzini wrote on Sat, Oct 23, 2010 at 09:38:43AM CEST:
> >>Also, libtool should probably ignore --with-sysroot if build==host;
> >>native compilers are never build with a sysroot in practice.
> >
> >OK, so this would mean there is no way --with-sysroot could be (ab)used
> >to fix the DESTDIR (re)link failures that libtool users experience
> >today.  Desired side-effect?
> 
> No, do you have a pointer?

It would be the next more complex step from tests/destdir.at:
package A provides libA, installed below $(DESTDIR)$(libdir),
package B provides libB depends on libA, installed below same,
package C provides Prog depends on libB.  Depending on how you
pass flags, the installed libB.la either contains the path to
libA including the $(DESTDIR) prefix (which would be right when
C is built before the destdir is moved to the final location,
or afterwards (but then building C before moving will not work).

Anyway you do it, one of the situations will at least look in
the wrong directories (either /usr/lib with missing destdir
prefix, or $(DESTDIR)$(libdir) on the target system).

I haven't tried whether --with-sysroot helps to work around that,
but I kind of figured it would.

> I don't understand what failure is there
> that cannot be fixed by --enable-fast-install (so that relink
> doesn't happen at install time), no?

Relink may just expose the issue to be a hard failure, but the
wrong-directory search will be there no matter what, I think.

That said, --enable-fast-install still has issues on GNU/Linux, too.

> >The rest of your proposed patch could also be wrapped in
> >gcc/configure.ac, I'm not sure whether it belongs there rather than in
> >Libtool?
> 
> I don't recall if binutils needs to know about a sysroot.

It probably does.  At least there are switches for --with-sysroot in ld,
gold, and gdb.

> Another solution is to do the following renaming in GCC
> 
> --with-sysroot -> --enable-sysroot
> --with-build-sysroot -> --with-target-sysroot
> (not existing) -> --with-host-sysroot
> 
> The task of mapping from old to new arguments is given to the
> toplevel configure script; subdirectories _never_ see a
> $with_sysroot with a meaning other than the one Libtool uses.  To do
> this, the toplevel configure simply has to mangle the
> {host,build,target}_configure_args to include the correct args:
> 
> --without-sysroot for build_configure_args
> 
> --with-sysroot=${with_host_sysroot:-no}
> --enable-sysroot=${with_sysroot:-${enable_sysroot:-no}}
> for host_configure_args
> 
> --with-sysroot=${with_target_sysroot:-${with_build_sysroot:-no}}
> for target_configure_args.
> 
> The patch should be relatively small, so OE can backport it to 4.5
> if they wish.  Adjusting the docs and selling the idea on gcc@ is
> probably harder than writing it.

Oh yes.  I'm honestly unsure however which would be the best solution
/in principle/, even apart from the practical selling point and GCC
compatibility issues.  You have more experience with GCC.  While I don't
mind changing new Libtool API here if that helps, I do think we should
pursue a solution that is the most logical in the long term.

Thanks for looking into this,
Ralf