Date: Fri, 27 Oct 2017 01:19:34 -0700 From: Mark Millard <markmi@dsl-only.net> To: =?utf-8?Q?Eddy_Petri=C8=99or?= <eddy.petrisor@gmail.com> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? Message-ID: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> In-Reply-To: <CAK0XTWczya8vg_sQZPqz-ZyYZRMq1v6p%2Bjs90S%2BjaDHxo2=1gA@mail.gmail.com> References: <CAK0XTWczya8vg_sQZPqz-ZyYZRMq1v6p%2Bjs90S%2BjaDHxo2=1gA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Oct-26, at 11:23 PM, Eddy Petri=C8=99or =
<eddy.petrisor@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.
>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87903F19-EF1B-4242-B36E-379E31152D43>