From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5AF6813877A for ; Fri, 1 Aug 2014 14:36:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3F749E09AA; Fri, 1 Aug 2014 14:36:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 218E5E089E for ; Fri, 1 Aug 2014 14:36:23 +0000 (UTC) Received: from [192.168.1.195] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 504A534028E for ; Fri, 1 Aug 2014 14:36:22 +0000 (UTC) Message-ID: <53DBA5E0.9060809@gentoo.org> Date: Fri, 01 Aug 2014 10:36:16 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: crossdev and multilib interference References: <539F6B3C.7030807@gentoo.org> <539F8000.5080804@gentoo.org> <539F9E41.9050505@gentoo.org> <539FA536.3010401@gentoo.org> <53A034F4.2000900@gentoo.org> <53A04DF6.6050407@gentoo.org> <1403017001.11300.1.camel@rook> <20140619212023.GC4582@rathaus.eclipse.co.uk> <53A4954E.20002@gentoo.org> <20140801090512.GA17213@rathaus.eclipse.co.uk> In-Reply-To: <20140801090512.GA17213@rathaus.eclipse.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: be5f4440-91de-431a-9d34-40415d2ac1e1 X-Archives-Hash: 495980fb28426a8816065b2eea8a9cde -----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 : >> >> >> >> 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-----