From owner-freebsd-toolchain@freebsd.org Fri Oct 27 06:23:31 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 C84CCE5D215; Fri, 27 Oct 2017 06:23:31 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 606C57D5A4; Fri, 27 Oct 2017 06:23:31 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wr0-x235.google.com with SMTP id r79so5159864wrb.13; Thu, 26 Oct 2017 23:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=rKwo2TBsUoMdMiyC6Q1LiaE5m1I+8pszWjLAGLtc1SA=; b=Ln1obPrHc6LLvwzvRtg/DekDXNkGGM88qoW9MRniMq+ywzGYYaemt7i/Eo31rJ4Uyx O4ihRwAM6rm/v97BLo5uHUPuoXQSP2jlkrxvQmJ7+7j8N8FB3z6+s70lpkz5cK/l0SUm fQo6OZuYGWjUAjE30dBnuR4XuQV/wnrbHde9tISuGdrxbJkbR/S7qUgslDtCofJ1l/Ds SWSLbRkxunWrH9LPUzc3XMmbkHcblZxyP/K6TK+ePoCTGVZRPp9tlC1e+MpdTkUIPmwc y5D0YLXKZpz+vSc0Ff0QyrtZyC2/n+9cVad95OeZW7OPgPxUy7dpk3M81n7pHnGZTroc N66A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=rKwo2TBsUoMdMiyC6Q1LiaE5m1I+8pszWjLAGLtc1SA=; b=HO/z40kVxcwST2eFpFr8rMqZVVTurrmlBJyse/WF9GByjgEIWwDlne8DODtH7yaxL7 9/ltwQRVI3ecu91J23gNcX5NlXi86z+43u4BYhpQHcxBUxHIGINgGr0Gs3UH7OQiWs6S IDco+DGexBIGB3iEzG0rNbZY1+21eEaeuCnjlvxSmkYszo2e2uPlyaz1+LkRctvHQRtT eRLWoR8L+w1IdYsx3G31J1INpitIym2dpheKA3va22x3QiBJUBP3ozH0G17LULyVZ9zi Nt3YUB+3fNfE57sU+yG+jPPP1lFAsRZKcn7BdLV4bkC+q9lhgOGa02P1i0kENih5foSS Fpkw== X-Gm-Message-State: AMCzsaUx1uZCePkgU3Qc9DVG29I7TeJRFJPRJQyNeMJSZsOAQ92cMaOu Lol6Sx1oqN3gC9lniiXu1MQRaf5z1fXo5hGKHW+AFnuw X-Google-Smtp-Source: ABhQp+Q6uSVJ13d+EXAP/N1INvDB5eFiB32AgiDtCrwuwAMpi45MTki97aW0FMANEf2B6OZm9h+XSVD54OsJEgOzZiE= X-Received: by 10.223.176.14 with SMTP id f14mr7030451wra.129.1509085409639; Thu, 26 Oct 2017 23:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Thu, 26 Oct 2017 23:23:29 -0700 (PDT) From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Fri, 27 Oct 2017 09:23:29 +0300 Message-ID: Subject: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? To: freebsd-toolchain@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 06:23:31 -0000 Hello, 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. .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 TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TA= RGET_ABI} BUILD_TRIPLE?=3D ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} 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 .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 + TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TA= RGET_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 What do you think, should the code be instead: .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 TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TA= RGET_ABI} +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} --=20 Eddy Petri=C8=99or 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 From owner-freebsd-toolchain@freebsd.org Fri Oct 27 22:10: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 BFA62E51E4B; Fri, 27 Oct 2017 22:10:44 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53BE47D04B; Fri, 27 Oct 2017 22:10:44 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id 15so7379298wrb.5; Fri, 27 Oct 2017 15:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lrTBgziPwdngYtbvIzI07s3ktWFij2n5T8R8Mr4+zmU=; b=YGuFZtKT+EkgGdtfi+rHCptyjSudhqX7ZEw8M0/hILII7aBgEXp9Gtd4bKo9Emd74z Osk3FHb+ON8YJd75pYlAcFbG67Evm3n6HUEyywRsqrssxvzsp7TBlNb58UifdrrWqnaR pCwHFwMLWVt+LDH+wjx5o7+To81O+QosRZPyey+uI8wtELBhkzZsrGWt2d6rlSwigd5A pEm4adPKVT9Mh8dqhRgj5T/5tT8Al22fhH+FKmxJQwj6r3TY1O99Eil8JxuD4+sTT8MY 43+Wgay565fZMcq8RXpl9cE9zFr9UPn7TJAQgR6ljuciHJVveHoX1ThMdc6JCwga85MB iBFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lrTBgziPwdngYtbvIzI07s3ktWFij2n5T8R8Mr4+zmU=; b=sYnjB8pRqMvbeEK9mskBBwIm+QWXVi6fib5muk8PdyaM1G1OCgCIxDl82D0haST+EW kMvHvWmR5pORNa1w+3D6HMSWvQLM7qtLhBVM/kpH0zJrnqIEuuIOG/NdOf408EddlKmd fGm78BfFUWcRFH2P/5srutgH983dAs6zMyU9EbAGSay8uZUD+YegtHwyIDAsEffBESrp JgBolGhUjCC7wPDmMCqty5vKsbIpmVNhG5uYfvBPaM/NsWz2juzvLBjkd6veLM0RFOY4 YhjjY5hc7qgvBJG4SY/z79I9LqquRHyh+wLTVNZVXeQFszz7PLH5HJ3lDO8/kCtfTBFv 0GNw== X-Gm-Message-State: AMCzsaWcXcyoevFj34GtNUJ/viyvbqcYrpBQYFOOkvjbZLTzqdIV0Q7a ZPwnVn/R2QbCZQEC87RwOHxn9pB4japou6ryo6lhKXr/ X-Google-Smtp-Source: ABhQp+SbuOaxbaQh8/HbWkgGB2DYKrJcrqZj7Xcnw+kM7mgn9tOTi/sC9dGiJjjq1rX5A7e0c6i0Q4nh8Erns4Kds5s= X-Received: by 10.223.198.6 with SMTP id n6mr1391754wrg.200.1509142242794; Fri, 27 Oct 2017 15:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Fri, 27 Oct 2017 15:10:41 -0700 (PDT) In-Reply-To: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> References: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Sat, 28 Oct 2017 01:10:41 +0300 Message-ID: Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? To: Mark Millard Cc: FreeBSD Toolchain , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 22:10:44 -0000 2017-10-27 11:19 GMT+03:00 Mark Millard : > 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. >> >> .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 . I am kind of confused by this part since I expect the BUILD architecture would not be that often and arm system. Maybe in my wish to provide some context, I added too much and sabotaged my own question :) >> TARGET_TRIPLE?=3D >> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}$= {TARGET_ABI} >> BUILD_TRIPLE?=3D >> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >> >> >> 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 [..] > [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.] I am not that concerned about this aspect in the context of my proposal, especially since NetBSD's build.sh takes better care of this on the host side: https://github.com/NetBSD/src/blob/d0543c2b811d0d1d5748e02597d906e04743316b= /build.sh#L486 > 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? Why would a FreeBSD host compiler report the triple with -gnueabi suffix? OOTH, if we're talking about using clang, the exact triple reported by the actual toolchain would be used in the clang/llvm compilation to define -DLLVM_HOST_TRIPLE with the exact value that makes sense for the host triple, which seems the right choice anyway, at least to me. > # cc --version > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLV= M 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? My point exactly, gcc and clang are supposed to behave identically from an interface PoV, so I expect the BUILD_TRIPLE gotten via -dumpmachine to be identical between them. >> +.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. I was only wondering about BUILD_TRIPLE in the context of llvm building. > But for non-FreeBSD hosts, such as a Linux distribution, > might other mismatches with FreeBSD conventions > matter? (See earlier above.) If we're on a Linux host the BUILD_TRIPLE should be the one approrpiate for the linux host, not the FreeBSD. If your point is that I will have to take such things into account for the cross building from Linux, I am aware of that, but that's not that important now since I am still stuck in the bootstrap phase for the cross compiler (linux host, freebsd target). > 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? That's why I said "host 'cc -dumpmachine'". I didn't care much for now for all sorts of checks or corrections such as using HOST_CC, I was just curious if the idea of using the '-dumpmachine' output to define the BUILD_TRIPLE. > 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 yes, and the HOST_CC or whatever mechanism was chosen to select the host toolchain would have to pick the desired cc. But from what I can see here, the BUILD_TRIPLE would be correct for FreeBSD if using -dumpmachine. > # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --version > powerpc64-unknown-freebsd12.0-gcc (FreeBSD Ports Collection for powerpc64= ) 6.3.0 > 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. Are you saying that based on BUILD_TRIPLE there is some later BUILD_ARCH definition? That sounds wrong. --=20 Eddy Petri=C8=99or From owner-freebsd-toolchain@freebsd.org Fri Oct 27 23:13:11 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 BBA7BE52ECF for ; Fri, 27 Oct 2017 23:13:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-124.reflexion.net [208.70.210.124]) (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 7D9FC7E85C for ; Fri, 27 Oct 2017 23:13:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12248 invoked from network); 27 Oct 2017 23:06:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Oct 2017 23:06:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 27 Oct 2017 19:06:24 -0400 (EDT) Received: (qmail 19027 invoked from network); 27 Oct 2017 23:06:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Oct 2017 23:06:23 -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 317FDEC8A28; Fri, 27 Oct 2017 16:06:23 -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 16:06:21 -0700 Cc: FreeBSD Toolchain , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6BB7719D-6228-467E-ACA6-F849D290F9C4@dsl-only.net> References: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> 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 23:13:11 -0000 On 2017-Oct-27, at 3:10 PM, Eddy Petri=C8=99or wrote: > 2017-10-27 11:19 GMT+03:00 Mark Millard : >> On 2017-Oct-26, at 11:23 PM, 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 >> 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 . >=20 > I am kind of confused by this part since I expect the BUILD > architecture would not be that often and arm system. Maybe in my wish > to provide some context, I added too much and sabotaged my own > question :) I took your notes/questions/suggestions not as local workarounds based on your local context but as changes to FreeBSD materials themselves in order to more directly support bootstrapping and building from Linux in general. Looks like I got that wrong so most of my notes are not of much use to you. Sorry for the noise. >>> 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 >>=20 >> Using an arm FreeBSD head -r324743 context as an example. . . >>=20 >> For reference: >>=20 >> # grep BUILD_ARCH Makefile* >> Makefile.inc1:BUILD_ARCH!=3D uname -p >> Makefile.inc1:.if ${MACHINE_ARCH} !=3D ${BUILD_ARCH} >>=20 >>=20 >> # uname -ap >> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT r324743M arm armv7 > [..] >> [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.] >=20 > I am not that concerned about this aspect in the context of my > proposal, especially since NetBSD's build.sh takes better care of this > on the host side: > = https://github.com/NetBSD/src/blob/d0543c2b811d0d1d5748e02597d906e04743316= b/build.sh#L486 >=20 >> Back to the armv7 FreeBSD head -r324743 context. . . >>=20 >> # cc -dumpmachine >> armv7-unknown-freebsd12.0-gnueabihf >>=20 >> Compare that to the results of: >>=20 >> = ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} >>=20 >> 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? >=20 > Why would a FreeBSD host compiler report the triple with -gnueabi = suffix? > OOTH, if we're talking about using clang, the exact triple reported by > the actual toolchain would be used in the clang/llvm compilation to > define -DLLVM_HOST_TRIPLE with the exact value that makes sense for > the host triple, which seems the right choice anyway, at least to me. My example is what it does produce at the end: -gnueabihf Part of the reason is likely that FreeBSD allows building a soft-float based FreeBSD instead (still called armv7 ). hard-float based is just the default. The -dumpmachine output needs to indicate the distinction somehow. They choose to be explicit even in the default case (default from a FreeBSD point of view). This should apply to clang and to gcc for targeting FreeBSD. >> # 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 >>=20 >> 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? >=20 > My point exactly, gcc and clang are supposed to behave identically > from an interface PoV, so I expect the BUILD_TRIPLE gotten via > -dumpmachine to be identical between them. >=20 >>> +.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 >> Keeping the historical BUILD_ARCH content for FreeBSD >> hosts might be important. >=20 > I was only wondering about BUILD_TRIPLE in the context of llvm = building. >=20 >> But for non-FreeBSD hosts, such as a Linux distribution, >> might other mismatches with FreeBSD conventions >> matter? (See earlier above.) >=20 > If we're on a Linux host the BUILD_TRIPLE should be the one > approrpiate for the linux host, not the FreeBSD. > If your point is that I will have to take such things into account for > the cross building from Linux, I am aware of that, but that's not that > important now since I am still stuck in the bootstrap phase for the > cross compiler (linux host, freebsd target). >=20 >> 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? >=20 > That's why I said "host 'cc -dumpmachine'". I didn't care much for now > for all sorts of checks or corrections such as using HOST_CC, I was > just curious if the idea of using the '-dumpmachine' output to define > the BUILD_TRIPLE. >=20 >> 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: >>=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine >> powerpc64-unknown-freebsd12.0 >=20 > yes, and the HOST_CC or whatever mechanism was chosen to select the > host toolchain would have to pick the desired cc. >=20 > But from what I can see here, the BUILD_TRIPLE would be correct for > FreeBSD if using -dumpmachine. >=20 >> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --version >> powerpc64-unknown-freebsd12.0-gcc (FreeBSD Ports Collection for = powerpc64) 6.3.0 >=20 >> 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. >=20 > Are you saying that based on BUILD_TRIPLE there is some later > BUILD_ARCH definition? That sounds wrong. FreeBSD's original materials constructs BUILD_TRIPLE from BUILD_ARCH. That means that they agree, with BUILD_ARCH (from uname -p) leading the way. Your change no longer has this property: uname -p and cc -dumpmachine need not match (for the part of -dumpmachine output that may or may not be a match vs. the part that never matches). uname -p output did not have a stable definition across Linux distributions in my past experiments. uname -m might be a closer match by content to FreeBSD's uname -p. uname -m was stable in my little bit of experimentation. You might need a local workaround for BUILD_ARCH as well. Again: I misread the scope of the intended usage of the potential changes. So, I missed your interests. Mostly just ignore my original message. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Oct 28 11:12:16 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 44299E3F5ED; Sat, 28 Oct 2017 11:12:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DABD56C561; Sat, 28 Oct 2017 11:12:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::5d71:227a:7bb3:8fe3] (unknown [IPv6:2001:470:7a58:0:5d71:227a:7bb3:8fe3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1BB16FAED; Sat, 28 Oct 2017 13:12:07 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4487EF25-E903-4C28-9200-AB2D7E95F7F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 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'? Date: Sat, 28 Oct 2017 13:11:59 +0200 In-Reply-To: Cc: freebsd-toolchain@freebsd.org, freebsd-arm@freebsd.org To: =?utf-8?Q?Eddy_Petri=C8=99or?= References: 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: Sat, 28 Oct 2017 11:12:16 -0000 --Apple-Mail=_4487EF25-E903-4C28-9200-AB2D7E95F7F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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} 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. > To support a Linux host I made these changes that is using 'cc > -dumpmachine' to get the correct BUILD_TRIPLE, Unfortunately, this is the wrong option to do so. The gcc manual says: -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. E.g, it prints the *target* tripe, not the build triple. > 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 > + Again, this should be set by the top-level Makefiles, not in this one. >=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} No, this is definitely incorrect, as stated above. -Dimitry --Apple-Mail=_4487EF25-E903-4C28-9200-AB2D7E95F7F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWfRl/wAKCRCwXqMKLiCW o8fKAJ9cFTHTwp5Xa5nkDxxiefnU9mgmhACgiunmA7tOZhsUH2EPq4GNJQ5Ruqc= =9N23 -----END PGP SIGNATURE----- --Apple-Mail=_4487EF25-E903-4C28-9200-AB2D7E95F7F3-- From owner-freebsd-toolchain@freebsd.org Sat Oct 28 14:31:42 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 D2937E44BBA for ; Sat, 28 Oct 2017 14:31:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-118.reflexion.net [208.70.210.118]) (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 8926470E09 for ; Sat, 28 Oct 2017 14:31:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18879 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-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: Sat, 28 Oct 2017 14: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