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
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
