When cross-building from MacOS we have MACHINE=arm64 MACHINE_ARCH=arm,
so bsd.cpu.mk infers that sizeof(long) == 4, but of course it isn't.
This breaks the bootstrap build of openssl, which tests
MACHINE_ABI:Mlong64 to decide whether to build ecp_nistp224.c. It
doesn't, and crypto/openssl/freebsd/include/openssl/configuration.h
undefines OPENSSL_NO_EC_NISTP_64_GCC_128, so we end up with a link
error.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
share/mk/bsd.cpu.mk | ||||
---|---|---|---|---|
397 |
covers it too. No reason to have Darwin be special here. |
share/mk/bsd.cpu.mk | ||
---|---|---|
397 | That's fine for my immediate purposes but isn't it logically wrong? MACHINE/MACHINE_ARCH describe host architecture, so should be consistent across the whole build. Or is my my mental model wrong? |
share/mk/bsd.cpu.mk | ||
---|---|---|
397 | Well, in principle arm64/aarch32 is a valid ABI, no? |
share/mk/bsd.cpu.mk | ||
---|---|---|
397 | MACHINE/MACHINE_ARCH describes the architecture that you are currently generating binaries for. Initially that's the build machine, but during various buildworld/kernel steps MACHINE=TARGET MACHINE=TARGET_ARCH is done to switch what MACHINE* mean. If BOOTSTRAPPING is set that means MACHINE corresponds to the machine you're building on, because that switch has not yet happened. If BOOTSTRAPPING is not set that means MACHiNE corresponds to what was TARGET at the top level. But .MAKE.OS is always the build machine's OS. |
I kind of wonder if it makes sense to provide multiple host OS share/mk/bsd.cpu.mk files (or something similar) to avoid cluttering this file with support for a number of other OS hacks.
@sjg : do you have any thoughts on doing something like this? Has Juniper solved a similar problem in the past?
Does anyone have an objection to committing this? Cross-build testing on github is broken currently without it.
It's fine. I'd just watch out for adding more per-MACHINE/MACHINE_ARCH logic to the file.