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

[Mark Millard]

On 2017-Nov-4, at 6:02 PM, Mark Millard  wrote:

> On 2017-Nov-4, at 5:19 PM, Eddy Petrișor  wrote:
> 
>> Pe 5 nov. 2017 12:57 AM, "Gerald Pfeifer"  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

___
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"

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

[Mark Millard]

On 2017-Nov-4, at 5:19 PM, Eddy Petrișor  wrote:

> Pe 5 nov. 2017 12:57 AM, "Gerald Pfeifer"  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 .

===
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"

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

[Eddy Petrișor]

Pe 5 nov. 2017 12:57 AM, "Gerald Pfeifer"  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'.

Eddy Petrișor
___
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"

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

[Mark Millard]

On 2017-Nov-4, at 3:57 PM, Gerald Pfeifer  wrote:

> 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
> 
>  CONFIGURE_TARGET?=  ${ARCH}-portbld-${OPSYS:tl}${OSREL}
> 
> By default GCC would use the same as clang.

Interesting. Good to know. Thanks.

We still end up with depending on --dumpmachine giving
non-uniform results across typical compilers in a
standard FreeBSD environment. It looks like depending
on -dumpmachine should be avoided for any more than a
local workaround.

(Some Linux distributions might also vary such
definitions to be non-default as well for all
I know.)

===
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"