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