digitalmars.D.announce - Bug fixes for Mac OSX landing in 2.107.1
- Iain Buclaw (77/77) Feb 26 Hi,
- M. M. (2/8) Feb 26 Wow. Good job.
- Walter Bright (1/1) Feb 26 Wow! This is really good work. It's much appreciated!
- Mike Shah (4/10) Feb 26 This is great Ian! The unaligned pointers and macosx development
- Danilo (4/6) Feb 26 Will DMD still work with macOS 12.7.x and Xcode 14.2?
- Iain Buclaw (8/14) Feb 26 Yes, all issues reported by the Xcode 15 linker were subtle
- Danilo (2/13) Feb 27 Nice, thanks! 👍 🙏
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](https://github.com/dlang/dmd/pull/16221) This was caused by off-by-one mismatch in codegen symbol counters for the two tables. - [ld: unaligned pointer(s) for architecture x86_64](https://github.com/dlang/dmd/pull/16224) / 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_line` sections 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](https://github.com/dlang/dmd/pull/16227) Sometimes it was only seen with `dmd -O`, sometimes caused by `long * int` expressions. The underlying cause was symbol references being emitted as `X86_64_RELOC_GOT_LOAD` in the relocation table, but the instruction that accessed the symbol wasn't `MOVQ`. - [ld: address=0x0 points to section(2) with no content](https://github.com/dlang/dmd/pull/16222) This was triggered by g/shared array instantiated from a template and initialized with `[]` - such as the the variable `string[] 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_$](https://github.com/dlang/dmd/pull/16219) This was caused by `extern(Objective-C)` functions and/or variables being emitted as `align(3)`. - [ld: warning: no platform load command found, assuming: macOS](https://github.com/dlang/dmd/pull/16223) This was caused by a missing `LC_BUILD_VERSION` command in all compiled modules. Jacob Carlborg did [the hard work years ago](https://github.com/dlang/dmd/pull/10476) 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())](https://github.com/dlang/dmd/pull/16240) / 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_line` section. On developer machines, backtraces will still work as expected as D runtime supports getting this information instead via the `atos` command. Someone with a vested interest should look into adding `.dSYM` support to D runtime. (https://issues.dlang.org/show_bug.cgi?id=20510) - Setting `MACOSX_DEPLOYMENT_TARGET` now 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.
Feb 26
M. M. <matus email.cz> On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote: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. [...]Wow. Good job.
Feb 26
Wow! This is really good work. It's much appreciated!
Feb 26
On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote: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. [...]This is great Ian! The unaligned pointers and macosx development issue have plagued students for a long time (the workarounds were possible but confusing). Will give it a try after March 1st
Feb 26
On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote:This implies that the **minimum required version of DMD** to build on Mac OSX 13+ will be 2.107.1 / 2.108.x.Will DMD still work with macOS 12.7.x and Xcode 14.2? The Mac Pro x64 (waste bin model) doesn‘t get any updates anymore, as it first came out in 2013.
Feb 26
On Tuesday, 27 February 2024 at 06:08:51 UTC, Danilo wrote:On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote:Yes, all issues reported by the Xcode 15 linker were subtle corruptions of the mach-o format that are (mostly) silently accepted by the Xcode 14 and older linkers. MacOS 10.7 remains to be the absolute minimum version supported due to the requirement of native TLS. This'll only be bumped to 10.8/10.9 when coalesced sections get dropped (https://issues.dlang.org/show_bug.cgi?id=22464).This implies that the **minimum required version of DMD** to build on Mac OSX 13+ will be 2.107.1 / 2.108.x.Will DMD still work with macOS 12.7.x and Xcode 14.2? The Mac Pro x64 (waste bin model) doesn‘t get any updates anymore, as it first came out in 2013.
Feb 26
On Tuesday, 27 February 2024 at 07:48:20 UTC, Iain Buclaw wrote:Nice, thanks! 👍 🙏Will DMD still work with macOS 12.7.x and Xcode 14.2? The Mac Pro x64 (waste bin model) doesn‘t get any updates anymore, as it first came out in 2013.Yes, all issues reported by the Xcode 15 linker were subtle corruptions of the mach-o format that are (mostly) silently accepted by the Xcode 14 and older linkers. MacOS 10.7 remains to be the absolute minimum version supported due to the requirement of native TLS. This'll only be bumped to 10.8/10.9 when coalesced sections get dropped (https://issues.dlang.org/show_bug.cgi?id=22464).
Feb 27