Bug fixes for Mac OSX landing in 2.107.1

[Iain Buclaw]

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.