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

Mark Millard markmi at dsl-only.net
Sat Oct 28 15:31:42 UTC 2017


On 2017-Oct-28, at 4:11 AM, Dimitry Andric <dim at FreeBSD.org> wrote:

> On 27 Oct 2017, at 08:23, 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
>> 
>> 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}
> 
> 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.
> 
>> 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’s target machine (for example, ‘i686-pc-linux-gnu’)
>  -and don’t do anything else.

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

# clang -dumpmachine -m32
i386-unknown-freebsd12.0

But it does not change the gcc result:
(I happen to have only gcc7 around.)

# gcc7 -dumpmachine -m32
x86_64-portbld-freebsd12.0

# gcc7 -dumpmachine 
x86_64-portbld-freebsd12.0

(powerpc64 vs. powerpc is the same for
the -m32 handling for -dumpmachine .)

> 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=build) type of compiler command
in his intended environment(s).

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.

>> but I am wondering if
>> it shouldn't be OK for building on a FreeBSD host
>> 
>> .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
>> +
> 
> Again, this should be set by the top-level Makefiles, not in this one.
> 
>> 
>> 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
>> 
>> 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}
> 
> 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.

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




More information about the freebsd-arm mailing list