https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Mark Mentovai from comment #22) > (In reply to Iain Sandoe from comment #21) > > Thta is quite surprising - since the SDK should reflect the symbols exported > > by the libraries installed on the target system. Therefore, they should be > > present when the target is macOS 14; > > For the purposes of having appropriate declarations available for compiling, > the declarations in the SDK’s headers generally are annotated with > availability and obsolescence annotations. Apple is fairly good about this. > > For the purposes of linking, the SDK simply exposes the set of global > symbols exported by loadable modules, previously in stripped-down Mach-O > format containing little more than a symbol table, but nowadays (since SDK > 10.11) in .tbd format. Neither the Mach-O symbol table nor the .tbd format > have a way to express partial availability. The .tbd files are produced as a > simple export of the source Mach-O’s symbol table. (In reply to Mark Mentovai from comment #22) > (In reply to Iain Sandoe from comment #21) > > Thta is quite surprising - since the SDK should reflect the symbols exported > > by the libraries installed on the target system. Therefore, they should be > > present when the target is macOS 14; > > For the purposes of having appropriate declarations available for compiling, > the declarations in the SDK’s headers generally are annotated with > availability and obsolescence annotations. Apple is fairly good about this. > > For the purposes of linking, the SDK simply exposes the set of global > symbols exported by loadable modules, previously in stripped-down Mach-O > format containing little more than a symbol table, but nowadays (since SDK > 10.11) in .tbd format. Neither the Mach-O symbol table nor the .tbd format > have a way to express partial availability. The .tbd files are produced as a > simple export of the source Mach-O’s symbol table. OK. I don't want to argue about the details / usability etc. etc. ( but note that __symbols are for the implementation and the compiler is part of the implementation ). In principle, we should have dialogue between the compiler 'vendors' (we do upstream) - but usually the first we know about what's happening with SDKs is when something does not work. === So, the solutions that work are: 1. when building for macOS 14, use the macOS 14 SDK (that is actually my default action on all OS versions - use the last SDK provided for it). 2. Drop the legacy lib from macOS 14 as well. given that users will probably just use what xcrun gives them, 2 (as you propose) is probably least likely to get us a lot of bogus bug reports. I'll push this after a little more testing (and likewise on 14.2-darwin) other gcc versions can follow along once we've seen this bake a little on those.
