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