Permalink
Reply
Hi,
Over the last 2-3 years, there's been a slow build-up of issues on MacOS that have now come home to roost, and they could no longer be ignored/worked arounded in CI as GHA has made Xcode 15.0.1 the default SDK since ~end of January/February 2024.
RESOLVED: Linker errors
- ld: symbol count from symbol table and dynamic symbol table differ
This was caused by off-by-one mismatch in codegen symbol counters for the two tables. - ld: unaligned pointer(s) for architecture x86_64 / warning: alignment (1) of atom 'anon' is too small and may result in unaligned pointers / warning: pointer not aligned at address
This was caused by DMD forcing__debug_linesections to be emitted into the final executable to work around lack of backtrace support on OSX. This section now has the correct flags assigned to it so it gets discarded at link-time - see notes on BREAKING changes. - ld: GOT load reloc does not point to a movq instruction
Sometimes it was only seen withdmd -O, sometimes caused bylong * intexpressions. The underlying cause was symbol references being emitted asX86_64_RELOC_GOT_LOADin the relocation table, but the instruction that accessed the symbol wasn'tMOVQ. - ld: address=0x0 points to section(2) with no content
This was triggered by g/shared array instantiated from a template and initialized with[]- such as the the variablestring[] rt_options = []in D runtime - its empty initializer was being written to a data section that expected non-empty data.
RESOLVED: Linker warnings
- ld: warning: pointer not aligned at _OBJC_PROTOCOL$
This was caused byextern(Objective-C)functions and/or variables being emitted asalign(3). - ld: warning: no platform load command found, assuming: macOS
This was caused by a missingLC_BUILD_VERSIONcommand in all compiled modules. Jacob Carlborg did the hard work years ago to add support. Instead though a simplified version was committed that didn't include support for embedding CoreFoundation/framework/SDK version information in compiled objects - it wasn't necessary to fix the issue, and the linker fills in all SDK information for us anyway.
WONTFIX: Workarounds
- ld: Assertion failed: (slot < _sideTableBuffer.size()) / ld: Assertion failed: (resultIndex < sectData.atoms.size())
Whilst the cause is unknown, the trigger is by using DMD with Xcode 15.0.1. The assumption is that the linker supplied with Xcode 15.0.1 is unstable/buggy as code generated by GCC/G++/G... also triggered this assertion.
The confirmed fix is to upgrade to at least Xcode 15.1 / CommandLineTools for Xcode 15.1.
CHANGES:
- BREAKING: File/line information is no longer embedded into the executable via
__debug_linesection. On developer machines, backtraces will still work as expected as D runtime supports getting this information instead via theatoscommand. Someone with a vested interest should look into adding.dSYMsupport to D runtime. (https://issues.dlang.org/show_bug.cgi?id=20510) - Setting
MACOSX_DEPLOYMENT_TARGETnow results in its value being embedded into all compiled objects for macOS. An invalid setting will result in a compile-time error. - As a result of all the above issues, it is impossible to build anything with DMD when using Xcode 15. The interim workaround to build DMD itself is to use LDC as the host compiler. This will be resolved as soon as 2.107.1 is released.
This implies that the minimum required version of DMD to build on Mac OSX 13+ will be 2.107.1 / 2.108.x.
If there's interest in making an RC release ahead of 1st March so MacOS/x86 users can do any last minute checking, now would be the time to know. There's been no testing on any real world project.
Iain.
