From owner-freebsd-toolchain@freebsd.org Fri Oct 27 08:19:44 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35586E3AA03 for ; Fri, 27 Oct 2017 08:19:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-156.reflexion.net [208.70.210.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 862A680584 for ; Fri, 27 Oct 2017 08:19:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4246 invoked from network); 27 Oct 2017 08:19:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Oct 2017 08:19:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 27 Oct 2017 04:19:36 -0400 (EDT) Received: (qmail 14140 invoked from network); 27 Oct 2017 08:19:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Oct 2017 08:19:35 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2FD1AEC7C1F; Fri, 27 Oct 2017 01:19:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? From: Mark Millard In-Reply-To: Date: Fri, 27 Oct 2017 01:19:34 -0700 Cc: FreeBSD Toolchain , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> References: To: =?utf-8?Q?Eddy_Petri=C8=99or?= X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 08:19:44 -0000 On 2017-Oct-26, at 11:23 PM, Eddy Petri=C8=99or = wrote: > I am trying to make the FreeBSD code base build from a Linux host and > found this bit which defines BUILD_TRIPLE in a way which to my > untrained eyes look like overengineering. >=20 > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 I'm using a context where armv[67]* would now likely be in use above, in fact the context is from an armv7 build, no longer armv6 . > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > BUILD_TRIPLE?=3D > ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >=20 >=20 > To support a Linux host I made these changes that is using 'cc > -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if > it shouldn't be OK for building on a FreeBSD host Using an arm FreeBSD head -r324743 context as an example. . . For reference: # grep BUILD_ARCH Makefile* Makefile.inc1:BUILD_ARCH!=3D uname -p Makefile.inc1:.if ${MACHINE_ARCH} !=3D ${BUILD_ARCH} # uname -ap FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 # uname -m arm # uname -p armv7 (A little endian, hard float context by default.) Compare that to some Linux distributions: (extractions from an old exchange) On a Digi CCWiMX53 som (someone else sent this) (buildroot busybox): # uname -m armv7l # uname -p unknown I booted Ubuntu Mate on a BPI-M3 and tried: $ uname -p armv7l $ uname -ap Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 = 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux (Unfortunately I did not record -m for that back then but it matched -p results --from memory.) I tried another linux on the BPI-M3: gentoo . # uname -p ARMv7 Processor rev 5 (v7l) # uname -pa Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 = UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux # uname -m armv7l [After looking into the details my preliminary guess seemed to be correct: the only dependable uname output among -m -p -i was for -m for linux. The uname.c code used varies from distribution to distribution and that changed the other options' results.] Back to the armv7 FreeBSD head -r324743 context. . . # cc -dumpmachine armv7-unknown-freebsd12.0-gnueabihf Compare that to the results of: ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} Note that on FreeBSD itself on that machine BUILD_ARCH would historically not have the "-gnueabihf" suffix for such a host. Would the build tolerate it? # cc --version FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on = LLVM 5.0.0svn) Target: armv7-unknown-freebsd12.0-gnueabihf Thread model: posix InstalledDir: /usr/bin Note the "armv7" for what Linux might instead have something like "armv7l" for a little endian, hard-float context. Would this matter? Would the build tolerate a armv7l (or other such) in BUILD_ARCH? > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 > +BUILD_OS!=3D uname -s > + >=20 > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > +.if ${BUILD_OS} =3D=3D FreeBSD > BUILD_TRIPLE?=3D > ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} > +.else > +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine > +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} > +.endif Keeping the historical BUILD_ARCH content for FreeBSD hosts might be important. But for non-FreeBSD hosts, such as a Linux distribution, might other mismatches with FreeBSD conventions matter? (See earlier above.) Also: What of using alternative compilers (${CC} vs. cc in classic notations, may be ${HOST_CC} or some such here because multiple compilers can be involved)? Would "cc" always exist and be appropriate? In fact on FreeBSD it is possible to buildworld buildkernel using a non-system compiler, such as via the devel/powerpc64-gcc port, even on a powerpc64 system. (This allows a modern build instead of what gcc 4.2.1 is limited to since lang does not sufficiently yet.) For that context: # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine powerpc64-unknown-freebsd12.0 # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --version powerpc64-unknown-freebsd12.0-gcc (FreeBSD Ports Collection for = powerpc64) 6.3.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is = NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. > What do you think, should the code be instead: >=20 > .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} = =3D=3D "") > TARGET_ABI=3D -gnueabihf > .elif ${TARGET_ARCH:Marm*} > TARGET_ABI=3D -gnueabi > .else > TARGET_ABI=3D > .endif > VENDOR=3D unknown > OS_VERSION=3D freebsd12.0 >=20 > TARGET_TRIPLE?=3D > = ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${T= ARGET_ABI} > +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine > +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} I'd expect that the historical BUILD_ARCH content for a FreeBSD host should be kept instead of ending up with things like "-gnueabihf" tacked on sometimes. =3D=3D=3D Mark Millard markmi at dsl-only.net