deprecated linker options when targeting macOS 13; also potential ARM64 issues
"R. Matthew Emerson" <[email protected]> Wed, 24 Apr 2024 12:04:27 -0700
| Newsgroups | gmane.lisp.openmcl.devel |
|---|---|
| Message-ID | <[email protected]> |
In https://github.com/Clozure/ccl/issues/457, the reporter shows a bunch = of scary warnings when trying to build the lisp kernel with Xcode 15 = tools and targeting macOS 13. The alignment ones we can deal with. The other warnings I=E2=80=99m more = worried about. ld: warning: prefered load addresses (-seg1addr) are disabled with = chained fixups ld: warning: -no_pie is deprecated when targeting new OS versions ld: warning: prefered load addresses (-seg1addr) are disabled with = chained fixups ld: warning: non-standard -pagezero_size is deprecated when targeting = macOS 13.0 or later We can use the -no_fixup_chains linker option to silence the chained = fixup warnings. That means our link command would look like this: cc -Wl,-no_fixup_chains,-no_pie,-pagezero_size,0x10000,-seg1addr,0x10000 = ... But I=E2=80=99m not sure what to do about the warnings about -no_pie and = -pagezero_size. CCL wants to have some stuff laid out in fixed locations = in (relatively) low memory. If Apple gets rid of those options, I think = we=E2=80=99ll be in some trouble. As long as we pass, say, -mmacos-version-min=3D10.15, then we don=E2=80=99= t get the warnings, but future problems often arrive before you know it. I guess I=E2=80=99d better ask Apple at some point soon. I also just ran across https://developer.apple.com/forums/thread/655950, = which says "Modifying pagezero_size isn't a supportable option in the = arm64 environment. arm64 code must be in an ASLR binary, which using a = custom pagezero_size is incompatible with. An ASLR binary encodes signed = pointers using a large random size along with the expected page zero = size, and this combination is going to extend beyond the range of values = covered in the lower 32-bits.=E2=80=9D If that=E2=80=99s the case, then that may be an exciting problem for an = ARM64 port (well, an Apple silicon port in particular, I suppose). Maybe = we give up on controlling low memory and burn a register to point at the = necessary data. (There will also be certain hoops to jump through as described in = https://developer.apple.com/documentation/apple-silicon/porting-just-in-ti= me-compilers-to-apple-silicon)