[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: crossdev and multilib interference
From:       Michał Górny <mgorny () gentoo ! org>
Date:       2014-06-21 20:47:43
Message-ID: 20140621224743.5e43d868 () pomiot ! lan
[Download RAW message or body]


Dnia 2014-06-21, o godz. 03:31:30
Greg Turner <gmt@malth.us> napisał(a):

> On Fri, Jun 20, 2014 at 1:10 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> > Thoughts [about wrapping gcc, so that non-native multilib-build ABI's can
> finally return to a world where [[ ${GCC} != *' '* ]] ]?
> 
> TLDR: good idea, I'm strongly in favor of it.
> 
> A wrapper would fix horrors like the following, which, last I checked, was
> sort-of required* on ABI_X86="*32*" DEFAULT_ABI="amd64" systems with
> crossdev i686-pc-linux-gnu targets in ${PATH}:
> 
> [...]
> 
> But, it's not just that cmake can't properly handle a C{C,XX} variables
> with spaces in them**. There are a bunch of similar places where we had to
> patch Makefiles and autotools to wedge GCC="foo bar" support in.

I wasn't aware of that.

I honestly would love if toolchain cooperated with us on bringing this.
However, I'm a bit pessimistic about their willing. For one, we'd first
have to fix all multilib arches to use different CHOSTs for
different ABIs -- and so far, people prefer inventing some custom hacks
in the name of keeping status quo.

As far as multilib builds are concerned, I guess I could create
${T}/bin with proper wrappers. We do similar thing in python-r1 suite
already to make sure that all 'python[23]' calls behave correctly. Of
course, this will still require fixing CHOSTs and work only for
multilib ebuilds. But on the other hand, it would allow us to avoid
masking crossdev.

-- 
Best regards,
Michał Górny

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]