From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1SlPp7-0007Hh-Qp for garchives@archives.gentoo.org; Sun, 01 Jul 2012 19:28:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AC959E07DF; Sun, 1 Jul 2012 19:28:31 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 26CE7E07D2 for ; Sun, 1 Jul 2012 19:27:51 +0000 (UTC) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id AAF591B400C for ; Sun, 1 Jul 2012 19:27:50 +0000 (UTC) Received: by dadg9 with SMTP id g9so2217160dad.40 for ; Sun, 01 Jul 2012 12:27:49 -0700 (PDT) Received: by 10.66.73.70 with SMTP id j6mr16041188pav.5.1341170869641; Sun, 01 Jul 2012 12:27:49 -0700 (PDT) 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 Received: by 10.68.138.233 with HTTP; Sun, 1 Jul 2012 12:27:29 -0700 (PDT) In-Reply-To: <4FF03486.9020607@gentoo.org> References: <4FDC608C.8010708@gentoo.org> <4FDDC752.3080506@gentoo.org> <4FE0C207.6070302@gentoo.org> <20120619191644.7908fb03@googlemail.com> <4FE0CACF.4000401@gentoo.org> <20120619203602.GC4424@localhost> <4FEDBC23.70202@gentoo.org> <4FF03486.9020607@gentoo.org> From: Matt Turner Date: Sun, 1 Jul 2012 15:27:29 -0400 Message-ID: Subject: Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 83352981-9888-4154-9764-f9e6189725e6 X-Archives-Hash: 11ea984c6a04ac80b2e064039a0ef335 On Sun, Jul 1, 2012 at 7:29 AM, Thomas Sachau wrote: > Matt Turner schrieb: >> On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau wrote: >>> >> >> I'm interested in this because I'm regularly annoyed with the emul- >> packages and also because multilib is pretty important for mips. >> >>> If a package has dependencies, then those dependencies are required to have >>> at least the same targets enabled as the package >> >> That seems like the obvious (but perhaps naive) choice. What about >> depending on packages that don't install libraries, like x11-proto/ >> packages or generators like dev-util/indent? >> >> Maybe I just don't understand. Would these packages even have ABI flags? > > All packages do get the ABI flags (with the needed EAPI or via enabled > portage feature, which is currently in the multilib branch). > > If a package does not install anything ABI-specific (no headers, no libs > and no binaries), then there is no overhead, since it will just get > compiled/installed for one ABI, even if multiple ABI flags are enabled. I suppose that's just for ease of implementation? Not having to special-case packages that don't install binaries. That seem /okay/ to me, but I'm not writing the implementation so I only have so much weight. I would be interested to hear what Ciaran, Brian, and Zac think though. >> It's clear to me that libraries would be installed in different lib* >> directories dependent on their ABI, but how would typical executables >> be handled? > > By default, only the binaries for the first enabled ABI are preserved > (which usually is the default ABI). If you enable the abiwrapper USE > flag, the binaries for all target ABIs are preserved, installed in the > form of $binary-$ABI and $binary will be a symlink to a wrapper, which > calls the right binary for the currently selected ABI. Ahh, I see. That sounds reasonable. >> For mips, we'd like to have gcc built as an n64 binary, which would >> require its run-time dependencies (mpfr, mpc, gmp, etc.) to be >> available as n64 as well, but the rest of the system to be n32 >> binaries. Does this fit with your understanding (and proposed >> solution) of the problem? > > I guess, you require additional n64 libs for gcc dependencies like mpfr, > mpc and others, while your default ABI will be n32. > > This should work fine with my proposal, you just have the (already > default enabled) n32 ABI flag enabled, which results in everything being > built just for n32. For the packages, where you require additional n64 > libs, you just enable the n64 ABI flag in addition. And if you need n64 > binaries too, you enable the abiwrapper USE flag for them. One follow-on question. Consider having a package dev-libs/libpkg already installed for ABI="n32 -n64" and wanting to emerge another package that depends on it with ABI="-n32 n64". Will dev-libs/libpkg have to be rebuilt twice (once for the existing n32 ABI and again for the newly needed n64), or can we optimize this case by recognizing that building for multiple ABIs means entirely separate builds? Thanks, Matt