Page MenuHomeFreeBSD

Fix non-FreeBSD host lib32 build for TARGET=amd64
ClosedPublic

Authored by arichardson on Aug 22 2018, 1:24 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 13 2024, 7:20 AM
Unknown Object (File)
Oct 13 2024, 7:20 AM
Unknown Object (File)
Oct 13 2024, 7:20 AM
Unknown Object (File)
Oct 13 2024, 7:18 AM
Unknown Object (File)
Oct 10 2024, 5:57 PM
Unknown Object (File)
Sep 25 2024, 12:27 AM
Unknown Object (File)
Sep 22 2024, 1:12 AM
Unknown Object (File)
Sep 20 2024, 8:59 PM
Subscribers

Details

Summary

We need to pass an explicit target triple to clang otherwise it will
attempt to build with the host triple. This also has advantages when
building on a FreeBSD host: we now tell clang that we are targeting at least
FreeBSD 12.0 instead of an older version so it can enable newer features.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Seems fine to me.

We should probably find a way to define "freebsd12.0" in one place, not scattered around, but it's not critical here.

This revision is now accepted and ready to land.Aug 22 2018, 3:48 PM

Agreed that as a followup we should define a single variable in src/Makefile.inc1 to hold 'freebsd12.0'. Will be useful since we are about to bump it to 13 in a few weeks.

Makefile.libcompat
17 ↗(On Diff #47092)

So sadly this might not work when building with external GCC ('make CROSS_TOOLCHAIN=amd64-gcc' after 'pkg install amd64-xtoolchain-gcc' is how you would test). What I've found in my mips work is that I've had to resort to something like this:

.if ${WANT_COMPILER_TYPE} == gcc || \
    (defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
.else
XXX clang bits
.endif

In particular, when building with CROSS_TOOLCHAIN=amd64-gcc, WANT_COMPILER_TYPE will be clang (since that is /usr/bin/cc in the target) but X_COMPILER_TYPE will be gcc. I've talked to Bryan and knows this is cranky. We really want some kind of COMPILER_TYPE_IM_ACTUALLY_USING_RIGHT_NOW but with a better name.

This revision was automatically updated to reflect the committed changes.

I don't get emails for phabricator emails.
I do get and respond to IRC usually instantly.
Please get my feedback for further build changes.

In D16842#359095, @jhb wrote:

Agreed that as a followup we should define a single variable in src/Makefile.inc1 to hold 'freebsd12.0'. Will be useful since we are about to bump it to 13 in a few weeks.

It's called TARGET_TRIPLE

I don't get emails for phabricator emails.
I do get and respond to IRC usually instantly.
Please get my feedback for further build changes.

Sorry!

Please feel free to revert all my changes.

In D16842#359095, @jhb wrote:

Agreed that as a followup we should define a single variable in src/Makefile.inc1 to hold 'freebsd12.0'. Will be useful since we are about to bump it to 13 in a few weeks.

It's called TARGET_TRIPLE

I feel like TARGET_TRIPLE alone doesn't work. For example for mips I have to use 'mips-unknown-freebsd12.0' for lib32 when TARGET_TRIPLE is 'mips64-unknown-freebsd12.0'.

In D16842#381595, @jhb wrote:
In D16842#359095, @jhb wrote:

Agreed that as a followup we should define a single variable in src/Makefile.inc1 to hold 'freebsd12.0'. Will be useful since we are about to bump it to 13 in a few weeks.

It's called TARGET_TRIPLE

I feel like TARGET_TRIPLE alone doesn't work. For example for mips I have to use 'mips-unknown-freebsd12.0' for lib32 when TARGET_TRIPLE is 'mips64-unknown-freebsd12.0'.

This should hopefully be fixed in upstream LLVM soon. There was a commit recently that adjusts the MIPS triple depending on the -mabi= flag. However, I think it happened after the 7.0 release.