From owner-freebsd-arm@freebsd.org Sat Oct 28 15:31:42 2017 Return-Path: Delivered-To: freebsd-arm@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 0F8A1E4621C for ; Sat, 28 Oct 2017 15:31:42 +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 C7A55726ED for ; Sat, 28 Oct 2017 15:31:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1949 invoked from network); 28 Oct 2017 14:31:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Oct 2017 14:31:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 28 Oct 2017 10:31:34 -0400 (EDT) Received: (qmail 12211 invoked from network); 28 Oct 2017 14:31:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Oct 2017 14:31:34 -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 CB080EC8676; Sat, 28 Oct 2017 07:31:33 -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: Sat, 28 Oct 2017 07:31:33 -0700 Cc: =?utf-8?Q?Eddy_Petri=C8=99or?= , freebsd-arm , freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> References: To: Dimitry Andric X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 15:31:42 -0000 On 2017-Oct-28, at 4:11 AM, Dimitry Andric wrote: > On 27 Oct 2017, at 08:23, Eddy Petri=C8=99or wrote: >>=20 >> 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 >>=20 >> 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 > I don't see much overengineering here? :) We simply trust BUILD_ARCH, > as it is passed in by the top-level Makefile.inc1. This is how most = of > these down-level Makefiles work. Running all kinds of commands to > figure out architectures and the like should be avoided in such > Makefiles. >=20 >> To support a Linux host I made these changes that is using 'cc >> -dumpmachine' to get the correct BUILD_TRIPLE, >=20 > Unfortunately, this is the wrong option to do so. The gcc manual = says: >=20 > -dumpmachine > Print the compiler=E2=80=99s target machine (for example, = =E2=80=98i686-pc-linux-gnu=E2=80=99) > -and don=E2=80=99t do anything else. Yep --and it is even more complicated: gcc vs. clang are sometimes different for the target listed. . . For example -m32 for amd64 changes the clang result: # clang -dumpmachine x86_64-unknown-freebsd12.0 # clang -dumpmachine -m32 i386-unknown-freebsd12.0 But it does not change the gcc result: (I happen to have only gcc7 around.) # gcc7 -dumpmachine -m32 x86_64-portbld-freebsd12.0 # gcc7 -dumpmachine=20 x86_64-portbld-freebsd12.0 (powerpc64 vs. powerpc is the same for the -m32 handling for -dumpmachine .) > E.g, it prints the *target* tripe, not the build triple. My guess is that Eddy was depending on plain cc being a "self hosting" (target=3Dbuild) type of compiler command in his intended environment(s). Various linux distributions patch uname and its -p code (for example). Even for the same kernel being in use, giving different textual results. -m seemed more stable in my limited testing. Everyplace that uses uname probably needs to be reviewed for a possible re-work. BUILD_ARCH and its use is an example. >> but I am wondering if >> it shouldn't be OK for building on a FreeBSD host >>=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 >> +BUILD_OS!=3D uname -s >> + >=20 > Again, this should be set by the top-level Makefiles, not in this one. >=20 >>=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 >>=20 >> 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} >=20 > No, this is definitely incorrect, as stated above. It certainly would not be appropriate for general use on FreeBSD: more of a local workaround for an odd context, not a general solution. =3D=3D=3D Mark Millard markmi at dsl-only.net