Page MenuHomeFreeBSD

crossbuild: handle bmake and uname reporting x86_64 instead of amd64
AbandonedPublic

Authored by arichardson on Feb 2 2018, 9:14 AM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 7:42 AM
Unknown Object (File)
Dec 13 2023, 5:39 AM
Unknown Object (File)
Sep 10 2023, 8:38 AM
Unknown Object (File)
Jun 18 2023, 12:04 AM
Unknown Object (File)
Jun 3 2023, 1:41 AM
Unknown Object (File)
May 14 2023, 6:19 AM
Unknown Object (File)
Jan 2 2023, 5:52 PM
Unknown Object (File)
Dec 1 2022, 11:33 AM
Subscribers
None

Details

Summary

This is the default value for ${MACHINE} on Linux and Mac and changing it
to amd64 is required in order to build FreeBSD on those systems.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 14776
Build 14895: arc lint + arc unit

Event Timeline

bdrewery requested changes to this revision.Feb 2 2018, 6:33 PM
bdrewery added inline comments.
Makefile
310–315

This shouldn't be needed with the share/mk/src.sys.env.mk changes since MACHINE will already be amd64 by the time this file is parsed.

include/Makefile
395–396

Testing this piece is weird because it's part of a totally different build system.
MACHINE=host WITH_DIRDEPS_BUILD=yes make -C include

I think your change and the two HOST_MACHINE[_ARCH] lines are not needed if you just fixup the arch in share/mk/host-target.mk. We'll definitey want @sjg signoff on touching that file though.

share/mk/src.sys.env.mk
57

A comment that this is for cross-os builds would help not cause this to be trimmed by accident.

This revision now requires changes to proceed.Feb 2 2018, 6:33 PM
Makefile.inc1
450–453

Is all this to prevent requiring TARGET_ARCH?

Also why have:
BUILD_ARCH!= uname -p
<hack BUILD_ARCH>

and also
HOST_MACHINE_ARCH!= uname -p
<hack HOST_MACHINE_ARCH>

why not have them both be
FOO!= tools/build/build_machine
FOO_ARCH!=toos/build/build_machine_arch

and put all the hacks there. amd64 isn't the only mismatch.

Makefile
313

quotes are incorrect here

include/Makefile
395–396

Yes, this looks questionable.... and there should be no need to touch host-target.mk

There should be a very clear distinction between the "host" and the "target"
"amd64" is a valid value for TARGET_MACHINE, that does not make it valid for "host"

In our build (Junos and FreeBSD) we use the pseudo MACHINE "host" to trigger building for the host and its objdir is named with the value of ${HOST_TARGET} eg. freebsd11-amd64 or linux3-x86_64
this makes it safe to cross build the same tree on multiple hosts.

arichardson marked 2 inline comments as done.

Use a script in tools/build/ instead of inline hacks

Use a script in tools/build/ instead of inline hacks

Right, I know I made this suggestion, but I'm still struggling to understand why we need it. That's not been articulated very well, so it's hard to comment on its suitability for the problem it's supposed to solve.

! In D14166#297774, @imp wrote:
Right, I know I made this suggestion, but I'm still struggling to understand why we need it. That's not been articulated very well, so it's hard to comment on its suitability for the problem it's supposed to solve.

So the problem is that lots of makefiles do stuff like .if exists(${MACHINE_ARCH}/foo) and without these changes I got build errors. It is probably only an issue during the bootstrap-tools, build-tools and cross-tools stages since I think after that TARGET_ARCH is used.

! In D14166#297774, @imp wrote:
Right, I know I made this suggestion, but I'm still struggling to understand why we need it. That's not been articulated very well, so it's hard to comment on its suitability for the problem it's supposed to solve.

So the problem is that lots of makefiles do stuff like .if exists(${MACHINE_ARCH}/foo) and without these changes I got build errors. It is probably only an issue during the bootstrap-tools, build-tools and cross-tools stages since I think after that TARGET_ARCH is used.

MACHINE_ARCH is set at the top level from TARGET_ARCH, which you should always be setting when building on a foreign OS. Or did you want to implement the default build of 'whatever is closest to the foreign OS's arch on FreeBSD'? So I'm having heartburn with the notion that we'd pollute ares of our build to enable this feature since I'm having trouble understanding its value. If so, the list of translations is also woefully incomplete as mips, arm and I think powerpc use different naming conventions as well. It would be better to say 'You must define TARGET_ARCH' on a foreign OS, I think, but I'm open to a better understanding that would change my mind on this point. I also have trouble understanding how it would make it past the 'this is the valid list of machine/machine_arch combinations we have' as well for the downstream makefiles to be an issue.

I think we should require TARGET and TARGET_ARCH for cross-os builds. However, I believe the values for MACHINE/MACHINE_ARCH are wrong when make is invoked as ${BMAKE} or ${TMAKE}: i.e. during legacy, build-tools, bootstrap-tools, cross-tools, kernel-tools. I can't remember which programs were failing because of this, I will try again and report back.

I think we should require TARGET and TARGET_ARCH for cross-os builds. However, I believe the values for MACHINE/MACHINE_ARCH are wrong when make is invoked as ${BMAKE} or ${TMAKE}: i.e. during legacy, build-tools, bootstrap-tools, cross-tools, kernel-tools. I can't remember which programs were failing because of this, I will try again and report back.

Looking at the code, I suspect you may be right... We use it not only for setting MACHINE in the WMAKE and IMAKE phases, but the host's MACHINE* is also implicitly used earlier for the BMAKE and TMAKE phases. We don't set MACHINE* there, so rely on the host's notion, which would lead to the problems you are reporting. Please let me know what your tests say, but I suspect it's more for 'tricking FreeBSD to run on the right host type' rather than just to make the default TARGET be right, in which case it may not be able to be helped...

I just managed to build FreeBSD on MacOS without these changes so it seems like my later changes to libegacy have made this mostly unncessary.
I believe the changes to include/Makefile and the toplevel Makefile for native-xtools are still required but I'm not sure how important it is to have these targets working on other operating systems.