Enable LIB32 option on aarch64, defaulting to YES; it had defaulted
to "broken". Add required variables for how to compile lib32 on
arm. Use /usr/include/arm for armv7 (32-bit) headers, analogous to
/usr/include/i386 on amd64. Omit libomp from lib32; it is not
supported on armv7.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 52517 Build 49408: arc lint + arc unit
Event Timeline
Makefile.inc1 | ||
---|---|---|
1084 | Can we hoist some kind of: .if ${TARGET_ARCH} == "amd64" LIBCOMPAT_INCLUDE_DIRS+=i386 .elif ${TARGET_CPUARCH} == "aarch64" LIBCOMPAT_INCLUDE_DIRS+=arm .endif so then these all become a single generic .for d in ${LIBCOMPAT_INCLUDE_DIRS) ... .endfor rather than having N copies of the same pattern? Ideally that'd be a separate change without the aarch64 bit and then this would just add to that. | |
share/mk/bsd.compat.mk | ||
146 | Doesn't your driver fix render this obsolete? We don't want this hack in the tree. | |
share/mk/src.opts.mk | ||
301 | ${__T:Maarch64*} would be more friendly to CheriBSD as we have other arm64 MACHINE_ARCHes |
lib/Makefile | ||
---|---|---|
207 | This also belongs in src.opts.mk for marking OPENMP broken in the same place arm does. I guess so should the powerpc check, really. Though I'll note I'm changing COMPAT_32BIT checks to be COMPAT_LIBCOMPAT == "32" (see https://reviews.freebsd.org/D40922) and that patch series will likely land before this one. |
Makefile.inc1 | ||
---|---|---|
1084 | The change seems reasonable; it could be folded into existing tests in bsd.compat.mk. It seems a little odd to change it ahead of time, though, as amd64 will be the only case at first. | |
lib/Makefile | ||
207 | Any plans on when to push that series? Looks like they are all approved. It would be easier for me to finish after that is in the tree. OPENMP isn't marked broken for arm, just defaults to no. But it is broken. I see that I can simplify this test slightly by testing MACHINE_ARCH for armv7. | |
share/mk/bsd.compat.mk | ||
146 | I think that depends on whether a bootstrap compiler is built. If that is the only change, I don't think it is. I had no problem on a machine doing cross-compiles and clang 15.x installed, but Mark Millard had problems on an arm64 with clang 16.0 without this change. (I had omitted it after adding the clang change.) |
Makefile.inc1 | ||
---|---|---|
1084 | On its own, sure, but as a preparatory commit for this I don’t think so. It’s the usual approach of “NFC refactor then extend”. | |
lib/Makefile | ||
207 | One of the reviews was still undergoing (ill-informed) debate when I commented this last night, but I plan to push it either later today or during the work day tomorrow, so shouldn’t be holding you up. | |
share/mk/bsd.compat.mk | ||
146 | We can patch the ports compilers to do it, and can bump the version for the in-tree compiler so it’s bootstrapped. I’m loathe to add a hack like this here if we can avoid it, which we should be able to. |
Makefile.inc1 | ||
---|---|---|
1084 | I thought to put the definition(s) in bsd.compat.mk, but that isn't included in Makefile.inc1. I'll put the definitions in Makefile.inc1 unless someone has a better idea. |
lib/Makefile | ||
---|---|---|
206–207 | Technically doesn't matter now we don't have v6 in-tree, but ${MACHINE_CPUARCH} != "arm" is what we use elsewhere |
lib/Makefile | ||
---|---|---|
206–207 | I can change it if you prefer/if it is more correct. btw, I looked at src.opts.mk, and I don't know why the existing rules there are not sufficient. I suspect that the wrong architecture is defined when src.opts.mk is included. |
lib/Makefile | ||
---|---|---|
206–207 | The compat + src.opts.mk story is a bit of a mess currently |
share/mk/bsd.compat.mk | ||
---|---|---|
69 | Oops, thanks for catching. |