[toolchain] lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?
Mark Millard
markmi at dsl-only.net
Sun Nov 5 01:28:45 UTC 2017
On 2017-Nov-4, at 6:02 PM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2017-Nov-4, at 5:19 PM, Eddy Petrișor <eddy.petrisor at gmail.com> wrote:
>
>> Pe 5 nov. 2017 12:57 AM, "Gerald Pfeifer" <gerald at pfeifer.com> a scris:
>> On Sun, 29 Oct 2017, Eddy Petrișor wrote:
>>> 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
>>
>> That's not actually related to GCC, but the lang/gcc* ports using
>> the FreeBSD Ports Collection's default that explicitly set
>>
>> Yes, I know. That's why I said the vendor part must be forced to "unknown".
>>
>>
>> CONFIGURE_TARGET?= ${ARCH}-portbld-${OPSYS:tl}${OSREL}
>>
>> By default GCC would use the same as clang.
>>
>> Sure, but that doesn't mean the vendor part of the triple in the default compiler is guaranteed to be 'unknown'.
>
> The "unknown" vs. "portbld" has a specific meaning
> for a FreeBSD context:
>
> unknown: it is a devel/* port
> portbld: it is a lang/* port
>
> This keeps the likes of devel/powerpc64-gcc
> and lang/gcc6 from having conflicting files
> on a powerpc64 FreeBSD machine, even when
> they are at the same (full) version.
>
> The variation that I intended to write about
> was the x86_64 vs. i386 variation when -m32
> is in use. That is a separate issue from
> unknown vs. portbld .
I forgot to mention that I also intended to
write about the -gnueabihf suffix vs. not
for armv7 between various normal FreeBSD
compilers (system and ports compilers).
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-arm
mailing list