Date: Sun, 29 Oct 2017 09:51:01 +0200 From: =?UTF-8?Q?Eddy_Petri=C8=99or?= <eddy.petrisor@gmail.com> To: Mark Millard <markmi@dsl-only.net> Cc: Dimitry Andric <dim@freebsd.org>, freebsd-arm@freebsd.org, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? Message-ID: <CAK0XTWdRjek6StRktBfn0oGMo1ixTohs6NPoyDx__QMQ56ki_g@mail.gmail.com> In-Reply-To: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> References: <CAK0XTWczya8vg_sQZPqz-ZyYZRMq1v6p%2Bjs90S%2BjaDHxo2=1gA@mail.gmail.com> <CDAA0CB5-F1FC-40FE-AEC5-56FD64654671@FreeBSD.org> <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Pe 28 oct. 2017 5:31 PM, "Mark Millard" <markmi@dsl-only.net> a scris:
On 2017-Oct-28, at 4:11 AM, Dimitry Andric <dim at FreeBSD.org> wrote:
> On 27 Oct 2017, at 08:23, Eddy Petri=C8=99or <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.
>> 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.
I understand. The stage I am at is building a cross compiler for x86_64
Linux host and whatever TARGET was chosen through TARGET and TARGET_ARCH.
>> 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.
Since my intention is to use the *host cc* to define the BUILD_TRIPLE on
non-FreeBSD systems, this is exactly what I wanted to accomplish so the
llvm/clang build will have the correct build triple for the foreign OS in
LLVM_HOST_TRIPLE, just 3 lines lower than the BUILD_TRIPLE definition.
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
..
# gcc7 -dumpmachine
x86_64-portbld-freebsd12.0
Hmm, from these examples and the different vendor part, the answer for a
BSD host compiler is clearly no.
I also found it strange that the ABI part is forced to 'freebsd12.0' no
matter if the host FreeBSD is head or older (e.g. 10.x or 11.x). I assume
this correct because the legacy stage makes sure the compatibility shims
are in place, correct?
For non-FreeBSD host, the vendor part looks like will need to be forced to
'unknown' for my idea to work more reliably.
> 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).
100% correct. This is trying to address the fact that using the
OS_VERSION=3Dfreebsd12.0 defintion to define the host compiler ABI makes no
sense for non-FreeBSD hosts, since the appropriate host ABI definitio could
be 'linux-gnu', 'linux-gneabi', 'darwin11*' etc.
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.
Yes, I have some places where I made MACHINE* related changes, and a
wrapper script to enforce some things to be correct for the
Linux-host--FreeBSD-target scenario.
See this wrapper, for example:
https://github.com/eddyp/freebsd/blob/linux-fixes/Linux.sh
>> but I am wondering if
>> it shouldn't be OK for building on a FreeBSD host
>>
>> +BUILD_OS!=3D uname -s
>> +
>
> Again, this should be set by the top-level Makefiles, not in this one.
I am aware of that. For the purpose of focusing the thread on the 'is the
host cc dumpmachine better at definig BUILD_TRIPLET' topic, I prefered to
present code only with local modifications.
My actual code is doing things like these:
https://github.com/eddyp/freebsd/commit/caf7995fac43453f4f84
3cb15d1696283e12b783
>> What do you think, should the code be instead:
[..]
>> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${
OS_VERSION}${TARGET_ABI}
>> +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine
>> +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE}
>
> 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.
Assuming 'odd context=3DLinux host', would you see something wrong, except
the need to overwrite the vendor part to 'unknown', if it exists?
For instance on Debian/Ubuntu amd64 I have:
eddy@feodora:~ $ uname -m ; uname -p ; uname -s ; uname -o ; uname -r
x86_64
x86_64
Linux
GNU/Linux
4.4.0-96-generic
eddy@feodora:~ $ cc -dumpmachine
x86_64-linux-gnu
eddy@feodora:~$ cc --version
cc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
Copyright (C) 2015 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.
And cc is actually pointing though the debian-alternatives mechanisms to
gcc.
eddy@feodora:~/usr/src/FreeBSD/freebsd$ ll `which cc`
lrwxrwxrwx 1 root root 20 mar 1 2016 /usr/bin/cc -> /etc/alternatives/cc*
eddy@feodora:~/usr/src/FreeBSD/freebsd$ ll /etc/alternatives/cc
lrwxrwxrwx 1 root root 12 mar 1 2016 /etc/alternatives/cc -> /usr/bin/gcc=
*
Eddy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK0XTWdRjek6StRktBfn0oGMo1ixTohs6NPoyDx__QMQ56ki_g>