lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

Fri Oct 27 13:46:24 UTC 2017

On 2017-Oct-26, at 11:23 PM, Eddy Petrișor <eddy.petrisor at gmail.com> 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*} == "")
> TARGET_ABI=    -gnueabihf
> .elif ${TARGET_ARCH:Marm*}
> TARGET_ABI=    -gnueabi
> .else
> TARGET_ABI=
> .endif
> VENDOR=        unknown
> OS_VERSION=    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?=
> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TARGET_ABI}
> BUILD_TRIPLE?=
> ${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!=	uname -p
Makefile.inc1:.if ${MACHINE_ARCH} != ${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*} == "")
> TARGET_ABI=    -gnueabihf
> .elif ${TARGET_ARCH:Marm*}
> TARGET_ABI=    -gnueabi
> .else
> TARGET_ABI=
> .endif
> VENDOR=        unknown
> OS_VERSION=    freebsd12.0
> +BUILD_OS!=    uname -s
> +
> 
> TARGET_TRIPLE?=
> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TARGET_ABI}
> +.if ${BUILD_OS} == FreeBSD
> BUILD_TRIPLE?=
> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}
> +.else
> +HOST_CC_DUMPMACHINE!=    cc -dumpmachine
> +BUILD_TRIPLE?=    ${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:
> 
> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} == "")
> TARGET_ABI=    -gnueabihf
> .elif ${TARGET_ARCH:Marm*}
> TARGET_ABI=    -gnueabi
> .else
> TARGET_ABI=
> .endif
> VENDOR=        unknown
> OS_VERSION=    freebsd12.0
> 
> TARGET_TRIPLE?=
> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TARGET_ABI}
> +HOST_CC_DUMPMACHINE!=    cc -dumpmachine
> +BUILD_TRIPLE?=    ${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.

===
Mark Millard
markmi at dsl-only.net