Date: Sat, 28 Oct 2017 01:10:41 +0300 From: =?UTF-8?Q?Eddy_Petri=C8=99or?= <eddy.petrisor@gmail.com> To: Mark Millard <markmi@dsl-only.net> 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: <CAK0XTWd%2BkbOL38LKTgTXARmbJDc=obsR9T5ONSc9btkiz4CVsw@mail.gmail.com> In-Reply-To: <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net> References: <CAK0XTWczya8vg_sQZPqz-ZyYZRMq1v6p%2Bjs90S%2BjaDHxo2=1gA@mail.gmail.com> <87903F19-EF1B-4242-B36E-379E31152D43@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2017-10-27 11:19 GMT+03:00 Mark Millard <markmi@dsl-only.net>:
> 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.
>>
>> .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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK0XTWd%2BkbOL38LKTgTXARmbJDc=obsR9T5ONSc9btkiz4CVsw>