Re: [gentoo-dev] Re: crossdev and multilib interference

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/08/14 05:05 AM, Steven J. Long wrote:
> On Fri, Jun 20, 2014, Ian Stakenvicius wrote:
>> On 19/06/14 05:20 PM, Steven J. Long wrote:
>>> Well I've spent far too long at crossdev code, only to see this
>>> and realise you can simply hard-mask:
>>> cross-i686-pc-linux-gnu/{binutils,gcc,glibc,pkg-config} in the
>>> amd64 multilib profile, unless I'm missing something. You'd be
>>>  hard-pushed to install a clashing crossdev with such a mask,
>>> afaict.
>>>
>>> If you do want to change crossdev[1], afaict you're looking at
>>> interaction between toolchain.eclass (and toolchain-binutils,
>>> and likely -funcs), crossdev and gcc-config. I could well be
>>> wrong, as ever. This is just my preliminary understanding, and
>>> maybe it'll provoke a more thorough explanation. [ Snip! ]
>>
>> Thank you for the explanation and research!
>
> YW :-) shove autotools.eclass (and supporting) in there too,
> including multiprocessing which had a simply painful attempt at
> cleverness. I mentioned it in #gentoo-embedded when i saw it, so
> hopefully it'll be corrected soon. (bashpid() function: if you
> can't see why it's painfully embarrassing, /join #bash and ask.)
>
>> Tangental to this, mgorny wrote a little tool yesterday that
>> might work well as an alternative to crossdev for multilib
>> systems.  It simply wraps all the native toolchain calls with
>> proper -m and provides the new CTARGETs.
>>
>> If anybody wants to take a look, this is the link he posted on
>> -dev :
>>
>> <dead url>
>>
>> Whether or not this suits everyone's needs for an i686 crossdev
>> on amd64 systems, i don't know.  Thoughts?
>
> It's more layer upon layer, I'm afraid. Though that file's gone
> from the repo, so I imagine it's already made its way to join the
> rest of the misguided hackery that is multilib. Still, it's good
> that his bash has come on, though he's still too tricksy for his
> own good; likely trying to emulate Frysinger, another one who needs
> a nice lie-down sometimes, instead of banging out more. Idiot
> house-"styles" will do that to you, as will C++.
>
> I don't know why we can't just mask cross-*/whatever in the
> multilib profile, instead of more talk of "masking crossdev" with a
> heavy heart.
>
> Nor do know if that's been done already, as I just found that the
> profiles directory Changelog stopped in 2013, for some reason, and
> I don't have time to chase the files right now.
>
> Sorry for delay, been away and then busy. I was hoping to read
> something more than "mask crossdev" yet again, when I got back.
>
> Regards, igli.
>

It's a package in the tree now, actually --
sys-devel/multilib-gcc-wrapper ; it wraps the native toolchain
appropriately for the different ABI's that this toolchain supports, so
that ie an i686-*-gcc call is implemented properly via the native gcc
instead of a crossdev one.  Note, it *also* works on multilib
crossdev, too!  I have a ppc crossdev installed on my amd64 host box
and multilib-gcc-wrapper allows it to build for both ppc32 and ppc64
ABIs just fine (presumably; i don't have a ppc32 or ppc64 native
system to actually do runtime tests).

Back to the comment on masking -- would a cross-emerge (which i think
uses the target's profile, right?) end up p.masking its own toolchain?
 If it did, would that actually break anything (i'm thinking no since
it's the crossdev that manages toolchain updates for the target rather
than cross-emerge)??  I agree that masks should be minimized, at most
masking the conflicting cross-* packages in a profile.  However if
this causes issues within cross-emerge too, then perhaps adjusting the
crossdev tool to warn or error would suffice when a target that will
conflict with the native toolchain is requested.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPbpeAACgkQ2ugaI38ACPCGRwD+JnA2ACNizXn9ZYG0kiaoitwO
wqHqahuceDxeo8z+Ps4A/158v8pElxPFZ4oWgHfVbZ43eiJm/N65Zay1x3U/vo3w
=m7AR
-----END PGP SIGNATURE-----