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"

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

[Eddy Petrișor]

2017-10-29 9:51 GMT+02:00 Eddy Petrișor :

> 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.
>
>
(format correction, this should have appeared as if said by Mark, but by
myself)

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

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: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

[Eddy Petrișor]

Pe 28 oct. 2017 5:31 PM, "Mark Millard"  a scris:

On 2017-Oct-28, at 4:11 AM, Dimitry Andric  wrote:

> On 27 Oct 2017, at 08:23, Eddy Petrișor 
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?=
>> ${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’s target machine (for example, ‘i686-pc-linux-gnu’)
>  -and don’t 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=build) type of compiler command
in his intended environment(s).


100% correct. This is trying to address the fact that using the
OS_VERSION=freebsd12.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!=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!=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.


Assuming 'odd context=Linux 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 

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

[Mark Millard]

On 2017-Oct-28, at 4:11 AM, Dimitry Andric  wrote:

> On 27 Oct 2017, at 08:23, Eddy Petrișor  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"

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

[Dimitry Andric]

On 27 Oct 2017, at 08:23, Eddy Petrișor  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.

E.g, it prints the *target* tripe, not the build triple.


> 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.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

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

[Mark Millard]

On 2017-Oct-27, at 3:10 PM, Eddy Petrișor  wrote:

> 2017-10-27 11:19 GMT+03:00 Mark Millard :
>> On 2017-Oct-26, at 11:23 PM, Eddy Petrișor  
>> 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
>> 
>> I'm using a context where armv[67]* would now
>> likely be in use above, in fact the context is
>> from an armv7 build, no longer armv6 .
> 
> I am kind of confused by this part since I expect the BUILD
> architecture would not be that often and arm system. Maybe in my wish
> to provide some context, I added too much and sabotaged my own
> question :)

I took your notes/questions/suggestions not as local
workarounds based on your local context but as changes
to FreeBSD materials themselves in order to more
directly support bootstrapping and building from Linux
in general.

Looks like I got that wrong so most of my notes are not
of much use to you. Sorry for the noise.

>>> 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}
>>> 
>>> 
>>> To support a Linux host I made these changes that is using 'cc
>>> -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if
>>> it shouldn't be OK for building on a FreeBSD host
>> 
>> Using an arm FreeBSD head -r324743 context as an example. . .
>> 
>> For reference:
>> 
>> # grep  BUILD_ARCH Makefile*
>> Makefile.inc1:BUILD_ARCH!=  uname -p
>> Makefile.inc1:.if ${MACHINE_ARCH} != ${BUILD_ARCH}
>> 
>> 
>> # uname -ap
>> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT  r324743M  arm armv7
> [..]
>> [After looking into the details my preliminary
>> guess seemed to be correct: the only dependable
>> uname output among -m -p -i was for -m for linux.
>> The uname.c code used varies from distribution
>> to distribution and that changed the other
>> options' results.]
> 
> I am not that concerned about this aspect in the context of my
> proposal, especially since NetBSD's build.sh takes better care of this
> on the host side:
> https://github.com/NetBSD/src/blob/d0543c2b811d0d1d5748e02597d906e04743316b/build.sh#L486
> 
>> Back to the armv7 FreeBSD head -r324743 context. . .
>> 
>> # cc -dumpmachine
>> armv7-unknown-freebsd12.0-gnueabihf
>> 
>> Compare that to the results of:
>> 
>> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}
>> 
>> Note that on FreeBSD itself on that machine BUILD_ARCH
>> would historically not have the "-gnueabihf" suffix for
>> such a host. Would the build tolerate it?
> 
> Why would a FreeBSD host compiler report the triple with -gnueabi suffix?
> OOTH, if we're talking about using clang, the exact triple reported by
> the actual toolchain would be used in the clang/llvm compilation to
> define -DLLVM_HOST_TRIPLE with the exact value that makes sense for
> the host triple, which seems the right choice anyway, at least to me.

My example is what it does produce at the end: -gnueabihf

Part of the reason is likely that FreeBSD allows building
a soft-float based FreeBSD instead (still called armv7 ).
hard-float based is just the default. The -dumpmachine
output needs to indicate the distinction somehow. They
choose to be explicit even in the default case (default
from a FreeBSD point of view). This should apply to
clang and to gcc for targeting FreeBSD.

>> # cc --version
>> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
>> 5.0.0svn)
>> Target: armv7-unknown-freebsd12.0-gnueabihf
>> Thread model: posix
>> InstalledDir: /usr/bin
>> 
>> Note the "armv7" for what Linux might instead have
>> something like "armv7l" for a little endian, hard-float
>> context. Would this matter? Would the build tolerate a
>> armv7l (or other such) in BUILD_ARCH?
> 
> My point exactly, gcc and clang are supposed to behave identically
> from an interface PoV, so I expect the BUILD_TRIPLE gotten via
> -dumpmachine to be identical between them.
> 
>>> +.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
>> 
>> Keeping the historical BUILD_ARCH content for FreeBSD
>> hosts might be important.
> 
> I was only wondering about BUILD_TRIPLE in the context of llvm building.
> 
>> But for non-FreeBSD hosts, such as a Linux distribution,
>> might other mismatches with FreeBSD conventions
>> matter? (See earlier above.)
> 
> If we're on a Linux host the BUILD_TRIPLE should be the one
> 

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

[Eddy Petrișor]

2017-10-27 11:19 GMT+03:00 Mark Millard :
> On 2017-Oct-26, at 11:23 PM, Eddy Petrișor  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
>
> I'm using a context where armv[67]* would now
> likely be in use above, in fact the context is
> from an armv7 build, no longer armv6 .

I am kind of confused by this part since I expect the BUILD
architecture would not be that often and arm system. Maybe in my wish
to provide some context, I added too much and sabotaged my own
question :)

>> 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}
>>
>>
>> To support a Linux host I made these changes that is using 'cc
>> -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if
>> it shouldn't be OK for building on a FreeBSD host
>
> Using an arm FreeBSD head -r324743 context as an example. . .
>
> For reference:
>
> # grep  BUILD_ARCH Makefile*
> Makefile.inc1:BUILD_ARCH!=  uname -p
> Makefile.inc1:.if ${MACHINE_ARCH} != ${BUILD_ARCH}
>
>
> # uname -ap
> FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT  r324743M  arm armv7
[..]
> [After looking into the details my preliminary
> guess seemed to be correct: the only dependable
> uname output among -m -p -i was for -m for linux.
> The uname.c code used varies from distribution
> to distribution and that changed the other
> options' results.]

I am not that concerned about this aspect in the context of my
proposal, especially since NetBSD's build.sh takes better care of this
on the host side:
https://github.com/NetBSD/src/blob/d0543c2b811d0d1d5748e02597d906e04743316b/build.sh#L486

> Back to the armv7 FreeBSD head -r324743 context. . .
>
> # cc -dumpmachine
> armv7-unknown-freebsd12.0-gnueabihf
>
> Compare that to the results of:
>
> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}
>
> Note that on FreeBSD itself on that machine BUILD_ARCH
> would historically not have the "-gnueabihf" suffix for
> such a host. Would the build tolerate it?

Why would a FreeBSD host compiler report the triple with -gnueabi suffix?
OOTH, if we're talking about using clang, the exact triple reported by
the actual toolchain would be used in the clang/llvm compilation to
define -DLLVM_HOST_TRIPLE with the exact value that makes sense for
the host triple, which seems the right choice anyway, at least to me.

> # cc --version
> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
> 5.0.0svn)
> Target: armv7-unknown-freebsd12.0-gnueabihf
> Thread model: posix
> InstalledDir: /usr/bin
>
> Note the "armv7" for what Linux might instead have
> something like "armv7l" for a little endian, hard-float
> context. Would this matter? Would the build tolerate a
> armv7l (or other such) in BUILD_ARCH?

My point exactly, gcc and clang are supposed to behave identically
from an interface PoV, so I expect the BUILD_TRIPLE gotten via
-dumpmachine to be identical between them.

>> +.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
>
> Keeping the historical BUILD_ARCH content for FreeBSD
> hosts might be important.

I was only wondering about BUILD_TRIPLE in the context of llvm building.

> But for non-FreeBSD hosts, such as a Linux distribution,
> might other mismatches with FreeBSD conventions
> matter? (See earlier above.)

If we're on a Linux host the BUILD_TRIPLE should be the one
approrpiate for the linux host, not the FreeBSD.
If your point is that I will have to take such things into account for
the cross building from Linux, I am aware of that, but that's not that
important now since I am still stuck in the bootstrap phase for the
cross compiler (linux host, freebsd target).

> Also: What of using alternative compilers (${CC} vs.
> cc in classic notations, may be ${HOST_CC} or some such
> here because multiple compilers can be involved)? Would
> "cc" always exist and be appropriate?

That's why I said "host 'cc -dumpmachine'". I didn't care much for now
for all sorts of checks or corrections such as using HOST_CC, I was
just curious if the idea of using the '-dumpmachine' output to define
the BUILD_TRIPLE.

> In fact on FreeBSD it is possible to buildworld
> buildkernel using a non-system compiler, such as
> via the devel/powerpc64-gcc port, even on a
> powerpc64 system. (This allows a 

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

[Mark Millard]

On 2017-Oct-26, at 11:23 PM, Eddy Petrișor  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

I'm using a context where armv[67]* would now
likely be in use above, in fact the context is
from an armv7 build, no longer armv6 .

> 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}
> 
> 
> To support a Linux host I made these changes that is using 'cc
> -dumpmachine' to get the correct BUILD_TRIPLE, but I am wondering if
> it shouldn't be OK for building on a FreeBSD host

Using an arm FreeBSD head -r324743 context as an example. . .

For reference:

# grep  BUILD_ARCH Makefile*
Makefile.inc1:BUILD_ARCH!=  uname -p
Makefile.inc1:.if ${MACHINE_ARCH} != ${BUILD_ARCH}


# uname -ap
FreeBSD bpim3 12.0-CURRENT FreeBSD 12.0-CURRENT  r324743M  arm armv7

# uname -m
arm
# uname -p
armv7

(A little endian, hard float context by default.)

Compare that to some Linux distributions:
(extractions from an old exchange)

On a Digi CCWiMX53 som (someone else sent this)
(buildroot busybox):

# uname -m
armv7l
# uname -p
unknown

I booted Ubuntu Mate on a BPI-M3 and tried:

$ uname -p
armv7l

$ uname -ap
Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 UTC 
2016 armv7l armv7l armv7l GNU/Linux

(Unfortunately I did not record -m for that back
then but it matched -p results --from memory.)

I tried another linux on the BPI-M3: gentoo .

# uname -p
ARMv7 Processor rev 5 (v7l)

# uname -pa
Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 UTC 2016 
armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux

# uname -m
armv7l

[After looking into the details my preliminary
guess seemed to be correct: the only dependable
uname output among -m -p -i was for -m for linux.
The uname.c code used varies from distribution
to distribution and that changed the other
options' results.]

Back to the armv7 FreeBSD head -r324743 context. . .

# cc -dumpmachine
armv7-unknown-freebsd12.0-gnueabihf

Compare that to the results of:

${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}

Note that on FreeBSD itself on that machine BUILD_ARCH
would historically not have the "-gnueabihf" suffix for
such a host. Would the build tolerate it?

# cc --version
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
5.0.0svn)
Target: armv7-unknown-freebsd12.0-gnueabihf
Thread model: posix
InstalledDir: /usr/bin

Note the "armv7" for what Linux might instead have
something like "armv7l" for a little endian, hard-float
context. Would this matter? Would the build tolerate a
armv7l (or other such) in BUILD_ARCH?

> .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
> +
> 
> 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

Keeping the historical BUILD_ARCH content for FreeBSD
hosts might be important.

But for non-FreeBSD hosts, such as a Linux distribution,
might other mismatches with FreeBSD conventions
matter? (See earlier above.)

Also: What of using alternative compilers (${CC} vs.
cc in classic notations, may be ${HOST_CC} or some such
here because multiple compilers can be involved)? Would
"cc" always exist and be appropriate?

In fact on FreeBSD it is possible to buildworld
buildkernel using a non-system compiler, such as
via the devel/powerpc64-gcc port, even on a
powerpc64 system. (This allows a modern build
instead of what gcc 4.2.1 is limited to since
lang does not sufficiently yet.) For that
context:

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine
powerpc64-unknown-freebsd12.0

# /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --version
powerpc64-unknown-freebsd12.0-gcc (FreeBSD Ports Collection for powerpc64) 6.3.0
Copyright (C) 2016 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.


> What do you think, should the code be instead:
> 
> .if ${TARGET_ARCH:Marmv6*} && 

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

[Eddy Petrișor]

Hello,

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}


To support a Linux host I made these changes that is using 'cc
-dumpmachine' to get the correct BUILD_TRIPLE, 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
+

 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}


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