From owner-svn-src-all@FreeBSD.ORG Wed May 28 16:46:11 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 400F8FB4; Wed, 28 May 2014 16:46:11 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id B18662B24; Wed, 28 May 2014 16:46:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 10EDD3804C; Wed, 28 May 2014 11:46:04 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id X0lon_D8Wm5C; Wed, 28 May 2014 11:46:04 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id F0D0838046; Wed, 28 May 2014 11:46:02 -0500 (CDT) Message-ID: <538612C9.4090508@freebsd.org> Date: Wed, 28 May 2014 09:46:01 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Konstantin Belousov , Warner Losh Subject: Re: svn commit: r266553 - head/release/scripts References: <20140527001811.3e9d3e8d@kalimero.tijl.coosemans.org> <05D1A11D-5985-42EA-84AD-209A8B51D391@bsdimp.com> <20140527093633.0a922e13@kalimero.tijl.coosemans.org> <85FABD2B-81BB-4E1A-B61E-4216A144A9DB@bsdimp.com> <20140527214038.17d00369@kalimero.tijl.coosemans.org> <13EB325C-3882-46AA-9B17-3BF19997C978@bsdimp.com> <20140528125027.6d0cc4fb@kalimero.tijl.coosemans.org> <5E038619-5921-4B7A-A4EE-D1E83614934B@bsdimp.com> <20140528152820.GA3991@kib.kiev.ua> <20140528154728.GB3991@kib.kiev.ua> In-Reply-To: <20140528154728.GB3991@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Baptiste Daroussin , src-committers@freebsd.org, Ian Lepore , svn-src-all@freebsd.org, Glen Barber , svn-src-head@freebsd.org, Tijl Coosemans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:46:11 -0000 On 05/28/14 08:47, Konstantin Belousov wrote: > On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote: >> On May 28, 2014, at 9:28 AM, Konstantin Belousov wrote: >> >>> On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote: >>>> Then we disagree on this point. However, the disagreement here is >>>> kinda foundational: to build a set of libraries or sys root, you have >>>> to have a MACHINE_ARCH to make it work. Even in our current system, we >>>> set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries >>>> (note: we don?t do this for mips). This means that if we do grow x32 >>>> support, we?ll need to grow a MACHINE_ARCH for it. That?s my point: >>>> all ABIs have MACHINE_ARCH associated with them, and those are the >>>> names users are used to specifying, and are the ones that are the most >>>> natural for script writers to use. With nathan?s patches, we?re to the >>>> point where those are used, though there?s also the option of using >>>> the non-standard names if you want (e.g. amd64:32 instead of x32). >>>> >>> I am not sure if this comment would add anything to the discussion, >>> but other build systems do not require MACHINE_ARCH. In our terms, >>> other build systems are happy to build: >>> i386 binary when MACHINE is amd64 and CFLAGS contains -m32; >>> x32 binary when MACHINE is amd64 and CFLAGS contains -mx32. >>> >>> For HEAD and stable/10 we finally reached the point where -m32 works, >>> on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least >>> this is true for dependencies limited to the base system, and not to the >>> ports (the later is since ports do not know about multiarch). >>> >>> It is limitation of our build that we require MACHINE_ARCH to build >>> other natively supported ABI binary on the host. Ideally, the hacks that >>> treat lib32 build as the cross-compilation would go away eventually. >> I doubt it. The MACHINE_ARCH is used to select which files to build. > Do I understand you right that the comment references e.g. a selection > of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion > into the build ? If yes, I cannot disagree with the statement. > > My note was about our build system which currently requires > full-fledged cross-build to even create i386 binary on amd64 vs. other > builds which consider this as a (often minor) variations of the host > target. Sure, some variances must be allowed, e.g. to select proper .S > file for the ABI, but we do not need cross-build to get i386 on amd64. Does it actually do that? "Full cross-build" implies it builds a new compiler, at least to me, but it just builds with -m32 and changes MACHINE_ARCH. In any case, I think we have gotten lots of issues crossed here. I'll try to separate them out: 1. We will not ever have mixed-and-matched x32 and amd64 packages on one system without a massive overhaul of ports, since you can't link x32 binaries against amd64 libraries and vice versa. Handling that requires more dependency tracking and, at a minimum, something like /usr/local/lib-$MACHINE_ARCH. Maybe that's worth doing -- I don't know -- but it is very different from -fPIC and is an orthogonal discussion. 2. PowerPC is, as you note, arguably the most integrated 32/64-bit port we have, since it was originally specified as a 64-bit instruction set. 32-bit PowerPC is much more analogous to something like x32 than to i386. And it still has a different MACHINE_ARCH, needs a different C library and RTLD (and not through #ifdef!), etc. 3. The whole discussion was originally about what we call packages. Do we use the same arbitray names that the base system and ports use, or do we use different arbitrary names? That I think has been resolved. I suspect the actual patches got lost in this very long thread, so I'll forward them to freebsd-ports@ shortly. -Nathan