The build fails during the compilation of the libgcc_s.1.dylib library with: :info:build Undefined symbols for architecture x86_64: :info:build "___deregister_frame_info", referenced from: :info:build -reexported_symbols_list command line option :info:build "___deregister_frame_info_bases", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_info", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_info_bases", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_info_table", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_info_table_bases", referenced from: :info:build -reexported_symbols_list command line option :info:build "___register_frame_table", referenced from: :info:build -reexported_symbols_list command line option :info:build ld: symbol(s) not found for architecture x86_64 :info:build collect2: error: ld returned 1 exit status :info:build make[3]: *** [libgcc_s.1.dylib] Error 1 These symbols are indeed gone from macOS 15's version of libunwind.dylib A possible work-around is simply to avoid building the old libgcc_s.1.dylib. It's only there for backward compatibility. The hack below does this: diff --git a/libgcc/config/i386/t-darwin b/libgcc/config/i386/t-darwin index 4c18da1efbf..0f61dd53d75 100644 --- a/libgcc/config/i386/t-darwin +++ b/libgcc/config/i386/t-darwin @@ -6,4 +6,4 @@ LIB2FUNCS_EXCLUDE = _fixtfdi _fixunstfdi _floatditf _floatunditf SHLIB_MAPFILES += $(srcdir)/config/i386/libgcc-darwin.ver # Build a legacy libgcc_s.1 -BUILD_LIBGCCS1 = YES +# BUILD_LIBGCCS1 = YES Probably we want to refine this patch, only skip libgcc_s.1.dylib on macOS 15 and later (and retain it on macOS versions where it actually built fine).
yeah.. the compiler will not (for some several revisions) actually refer to libgcc_s.1.dylib - it is only there to support existing built exes from older compilers. Probably dropping it after macOS 14 is the best option - I'll look at amending the libgcc config to fix this. I don't have a macOS 15 install yet - running out of suitable hardware that is not already busy ....
Created attachment 59176 [details] Patch under test Please could folks with access to macOS 15 on x86_64 - test this (I will test on the older boxes where it is more likely to be a problem,
CN you prepare a version of the patch for the current gcc14 release ?
(In reply to Chris Jones from comment #3) > CN you prepare a version of the patch for the current gcc14 release ? I guess you tried applying the attached patch and it does not ? ---- you mean for the Arm64 development branch - or for upstream releases/gcc-14? (I will do both of course - but testing on trunk first)
Correct, i could not get it to apply against gcc 14.2
and yes, we are also using your patches for Darwin at https://github.com/iains/gcc-14-branch
Created attachment 59177 [details] patch for GCC-14 (***untested****) this is against the current darwin gcc-14 branch - it is completely untested.
(In reply to Iain Sandoe from comment #2) > Created attachment 59176 [details] > Patch under test Does not apply to upstream GCC. I think it needs "libgcc: limit to 11 from 11" https://github.com/iains/gcc-darwin-arm64/commit/1fa7e9c16c259be8d1e2110df5d317ca6ef69635 I've started a test of trunk with the two patches applied, on x86_64-apple-darwin24, and will report here. I'd argue that it makes a compelling case to push "libgcc: limit to 11 from 11" to trunk.
(In reply to Francois-Xavier Coudert from comment #8) > (In reply to Iain Sandoe from comment #2) > > Created attachment 59176 [details] > > Patch under test > > Does not apply to upstream GCC. I think it needs "libgcc: limit to 11 from > 11" > https://github.com/iains/gcc-darwin-arm64/commit/ > 1fa7e9c16c259be8d1e2110df5d317ca6ef69635 > > I've started a test of trunk with the two patches applied, on > x86_64-apple-darwin24, and will report here. I'd argue that it makes a > compelling case to push "libgcc: limit to 11 from 11" to trunk. yeah - that is pretty well-backed now .. let me test it individually. I'm limited at the moment because I'm already doing the weekly rebase build/test + limited hardware ( and even if I had more hardware limited enthusiasm for paying a higher electricity bill ;) )
The undefined symbols are things that libgcc_s.1 is trying to re-export from libunwind via libSystem. None of those functions ever worked on any Apple OS. They were present in Mac OS X 10.5 and 10.6, but broken. Since Mac OS X 10.7, they’ve been no-ops. In macOS 15, they’ve been removed entirely. There are other unwind functions, such as __{,de}register_frame, that remain in libunwind and libSystem. The no-op versions in libunwind since 10.7 (libunwind-30 is the version used in 10.7) can be seen at https://github.com/apple-oss-distributions/libunwind/blob/libunwind-30/src/UnwindLevel1-gcc-ext.c#L220. The modern version of that is https://github.com/llvm/llvm-project/blob/b7a249d26fe61432050df470d23bdea417fda574/libunwind/src/UnwindLevel1-gcc-ext.c#L282. Note that since https://github.com/llvm/llvm-project/commit/5eb44df1b64dbd1a86b099128092a7fd2001c0ba, these no-op functions are now only built if LIBUNWIND_ENABLE_FRAME_APIS is enabled, and it’s off by default. Similarly, these symbols were removed from llvm-libgcc in https://github.com/llvm/llvm-project/commit/be91bd012123de835f64e10e677b24a7580b273c. Because these functions were always non-working or non-functional, I’d be surprised to find anyone in the wild referring to them on macOS, so it’s almost certainly safe to remove them from libgcc_s.1 altogether without risking any binary compatibility concern, as Apple themselves have done in macOS 15 and in llvm-libgcc. This is my preferred option, as well as the simplest to implement. If there’s any remaining concern that someone might be referencing those symbols, it ought to be safe to implement them as either no-ops directly in libgcc_s.1 or to implement them as code that delegates to the libunwind (via libSystem) versions if present, and to function as a no-op otherwise. This is the safest option, but I don’t believe that it’s necessary. Eliminating libgcc_s.1 entirely runs the risk of breaking binary compatibility with code built by older toolchains that may reference that library (while not referencing the removed symbols from that library). I would tend to be more cautious about that approach, especially if targeting a merge back to a stable branch. But I haven’t done the research to determine how recently a toolchain may have imposed a run-time dependency on this library.
Indeed, all of this is well-known; NOTE: there is no change proposed for any OS < macOS 15. We actually bumped our libgcc_s version some time ago because GCC has for a while now been pulling the unwinder directly from libSystem (or /usr/lib/libgcc_s.1.dylib on darwin9). So GCC will not (for several releases now) be emitting any reference to libgcc_s.1.dylib - and on darwin9 (which actually needs the installed /usr/lib/libgcc_s.1.dylib) as said, there's no change proposed To use the GCC legacy lib - you'd have to use DYLD_LIBRARY_PATH to force point to an installation - otherwise the installed version in /usr/lib would (and should) be used anyway .. My view is that we want to remove this sometime - like Apple, eventually "legacy" has to be "we no longer care" .. so my preference is to remove it - and if we should get fallout - then we can consider an alternate solution with an edited symbols list.
Created attachment 59179 [details] Drop removed unwind symbols This implements what I referred to as my preferred option in comment 10. It should apply on the trunk and to all active branches.
Comment 12 was a Bugzilla mid-air with comment 11. I’m not arguing against comment 11, just offering an option that worked for me. Been a while since I’ve used Bugzilla regularly, I forgot about these quaint mid-airs…
(In reply to Mark Mentovai from comment #12) > Created attachment 59179 [details] > Drop removed unwind symbols > > This implements what I referred to as my preferred option in comment 10. It > should apply on the trunk and to all active branches. as specified, I think this will break Darwin <= 9 (and maybe ppc on 10) which still look up the frame info. the long-term goal here is to simplify the GCC as much as possible - we have such limited resources - so any removal is a bonus. --- NP about the mid-airs :) it happens...
(In reply to Mark Mentovai from comment #12) > Created attachment 59179 [details] > Drop removed unwind symbols > > This implements what I referred to as my preferred option in comment 10. It > should apply on the trunk and to all active branches. Given Iain’s concern, this should rather be tested first on 10.5–10.6. Having a broken gcc will be a disaster.
FAOD: - The current patch is to remove at macOS-15 - I have tested on systems that need to keep the lib - FX is testing on macOS 15. * I have already pushed the dependent patch that limits the libgcc range to 11+ from 11. * IFF we find that there are end-user issues with some weird way in which they are dependent on the GCC-installed libgcc_s.1 (that should really not happen) - then we will investigate pruning the symbols list (but that pruning would be matched to the system versions that it relates to - so there should be no concern in anyone's mind that we would be altering the behaviour for earlier ones). so .. as soon as I get a confirmation that this is working on macOS 15 (and likewise I have a queued patch on gcc-14-2-darwin) .. I'll land the fix.
(In reply to Iain Sandoe from comment #16) Got it, thank you very much.
I can confirm that the patch posted by Iain at https://gcc.gnu.org/bugzilla/attachment.cgi?id=59176 applied on top of (now pushed) https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=43eab54939d37d4e634a692910d31adafc053e38 does restore bootstrap on macOS Sequoia Intel and has no negative impact on the testsuite. It can be pushed.
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 commit r15-3839-gd9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 Author: Iain Sandoe <iain@sandoe.co.uk> Date: Sun Sep 22 11:43:32 2024 +0100 libgcc, Darwin: Drop the legacy library build for macOS >= 15 [PR116809]. We have been building a legacy libgcc_s.1 DSO to support code that was built with older compilers. From macOS 15, the unwinder no longer exports some of the symbols used in that library which (a) cuases bootstrap fail and (b) means that the legacy library is no longer useful. No open branch of GCC emits references to this library - and any already -built code that depends on the symbols would need rework anyway. PR target/116809 libgcc/ChangeLog: * config.host: Build legacy libgcc_s.1 on hosts before macOS 15. * config/i386/t-darwin: Remove reference to legacy libgcc_s.1 * config/rs6000/t-darwin: Likewise. * config/t-darwin-libgccs1: New file. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
Created attachment 59189 [details] Patch for macOS 14/Xcode 16 (In reply to GCC Commits from comment #19) > The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: > > https://gcc.gnu.org/g:d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > > commit r15-3839-gd9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > Author: Iain Sandoe <iain@sandoe.co.uk> > Date: Sun Sep 22 11:43:32 2024 +0100 > > libgcc, Darwin: Drop the legacy library build for macOS >= 15 [PR116809]. Unfortunately, this doesn’t resolve the bug in every place that it might be encountered. The bootstrapping problem occurs when targeting x86_64 and using the macOS 15 SDK. The macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. libgcc_s.1 can no longer be built on macOS 14 using Xcode 16 by the same logic that the above change disabled it for macOS 15.
(In reply to Mark Mentovai from comment #20) > Created attachment 59189 [details] > Patch for macOS 14/Xcode 16 > > (In reply to GCC Commits from comment #19) > > The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: > > > > https://gcc.gnu.org/g:d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > > > > commit r15-3839-gd9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > > Author: Iain Sandoe <iain@sandoe.co.uk> > > Date: Sun Sep 22 11:43:32 2024 +0100 > > > > libgcc, Darwin: Drop the legacy library build for macOS >= 15 [PR116809]. > > Unfortunately, this doesn’t resolve the bug in every place that it might be > encountered. > > The bootstrapping problem occurs when targeting x86_64 and using the macOS > 15 SDK. The macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. > libgcc_s.1 can no longer be built on macOS 14 using Xcode 16 by the same > logic that the above change disabled it for macOS 15. 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; Perhaps something not conditional in the way it should be - or it is depending on support for attribute ((availability)) which is only currently committed on darwin branches. If we build a compiler targeting macOS 15, but using xcode 16 on macOS 14 - then we should still eliminate the library.
(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. Because the libunwind symbols in question were never intended for user consumption, but were part of a loose contract with toolchains, there weren’t any viable declarations for them in SDK headers. The double-underscore prefix is a hint of this (the third underscore added as “C” name decoration). Where there were declarations (since SDK 10.7, in <unwind.h>), they were decorated with __attribute__((unavailable)). This is as good as there being no declaration at all. In fact, this still appears in SDK 15: #if defined(__APPLE__) #define LIBUNWIND_UNAVAIL __attribute__ (( unavailable )) #else #define LIBUNWIND_UNAVAIL #endif […] // Mac OS X 10.4 and 10.5 had implementations of these functions in // libgcc_s.dylib, but they never worked. /// These functions are no longer available on Mac OS X. extern void __register_frame_info_bases(const void *fde, void *ob, void *tb, void *db) LIBUNWIND_UNAVAIL; […] (from https://github.com/llvm/llvm-project/blob/1187d8a62ba288e2221731f1795fa184571cd854/libunwind/include/unwind.h#L169) But we’re not concerned with writing user code and calling these functions by #including <unwind.h> in libgcc_s.1. We’re simply concerned with re-exporting these symbols from libunwind, via the libSystem umbrella. That’s strictly a linker concern, and again, the input to the linker carries no information about availability, including partial availability or unavailability. If a symbol is present in a macOS runtime, whether the header annotates it as partially-available or unavailable or (absent an annotation) available without qualification, it will also appear in that same macOS version’s SDK, as the .tbd files are produced from the Mach-O files present in the runtime. So when the runtime drops a symbol entirely, as is the case in macOS 15 for these libunwind symbols, they disappear from the SDK as well. And when you build against the macOS 15 SDK to target macOS 14 or an earlier version, you lose access to the symbols dropped by macOS 15. Largely, this is working as intended. The only reason that Apple felt comfortable dropping these symbols from the runtime at all was that they believed they were entirely unused. I explained this and provided further justification in comment 10 (although I felt you kind of brushed that off—no offense taken, though) in support of the idea that libgcc_s.1 could feasibly drop the symbols as well, as I proposed in attachment 59179 [details]. If anyone had been using those symbols, and successfully linked against a previous SDK, that code would not have run on macOS 15, because the symbols are no longer part of the runtime. They’re only safe to remove from the runtime if no code references them, and if no code references them, then they’re also safe to remove from the SDK. > Perhaps something not conditional in the way it should be - or it is > depending on support for attribute ((availability)) which is only currently > committed on darwin branches. Do Not Adjust Your Set. Availability is working as it should. This example is iains/gcc-14-branch gcc-14-2-darwin: mark@arm-and-hammer zsh% gcc -x c -c -o /dev/null - <<< 'void U() __attribute__((unavailable)); void F() { U(); }' <stdin>: In function 'F': <stdin>:1:1: error: 'U' is unavailable <stdin>:1:6: note: declared here > If we build a compiler targeting macOS 15, but using xcode 16 on macOS 14 - > then we should still eliminate the library. Yes. But it’s difficult to cleanly detect what Xcode version you’re using, or perhaps more directly, whether libSystem exposes any of these symbols. You could do it with a configure check, but that seems like a little much for a handful of symbols that nobody’s using. Another option is to eliminate them from macOS 14 regardless of the SDK in use (attachment 59189 [details]).
(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.
(In reply to Iain Sandoe from comment #23) > 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. I mentioned the __ thing only to illustrate how these are a little outside of the normal application of the SDK. Apple’s made it pretty clear over the years that they consider themselves to own the entire implementation, end-to-end, privately. This isn’t just a GCC problem. They’ve bought into clang in a very big way and contribute to open-source LLVM. Trunk clang still has incompatibilities with the newly released macOS 15 SDK (example: https://chromium-review.googlesource.com/c/5622510/comments/04615850_0139eb2f). > 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). Infeasible, though. It’s been a very long time since Apple bundled more than one SDK per platform in Xcode. (The last time they did was Xcode 6.4 in 2015, with 10.9 and 10.10 SDKs, and some early Xcode 7.0 betas.) I really liked picking-and-choosing an appropriate SDK, but Apple decided that availability annotations were good enough for developer purposes and moved everything over to a single SDK only. > 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. Yeah, exactly. It’s not even going to be a matter of “what xcrun gives them”, there will be a large enough number of macOS 14 systems with developer tools but a macOS 15 SDK instead of a macOS 14 SDK. The SDKs are going to be updated in the wild, I don’t think GCC has much of an option to try to require that macOS 14 stick with that exact SDK.
(In reply to Mark Mentovai from comment #24) > (In reply to Iain Sandoe from comment #23) > > 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. > > I mentioned the __ thing only to illustrate how these are a little outside > of the normal application of the SDK. > > Apple’s made it pretty clear over the years that they consider themselves to > own the entire implementation, end-to-end, privately. > > This isn’t just a GCC problem. They’ve bought into clang in a very big way > and contribute to open-source LLVM. Trunk clang still has incompatibilities > with the newly released macOS 15 SDK (example: > https://chromium-review.googlesource.com/c/5622510/comments/ > 04615850_0139eb2f). 1. but you have identified that this cannot work when symbols are removed from a library .. as we see here 2. That is definitely not the case for CLT - and I do not install Xcode (i have too many test boxes) $ ls /XC/14.1/CommandLineTools/SDKs/ MacOSX.sdk MacOSX12.3.sdk MacOSX12.sdk MacOSX13.0.sdk MacOSX13.sdk $ ls /XC/15.1b/CommandLineTools/SDKs/ MacOSX.sdk MacOSX13.3.sdk MacOSX13.sdk MacOSX14.0.sdk MacOSX14.sdk > > 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). > > Infeasible, though. It’s been a very long time since Apple bundled more than > one SDK per platform in Xcode. (The last time they did was Xcode 6.4 in > 2015, with 10.9 and 10.10 SDKs, and some early Xcode 7.0 betas.) I really > liked picking-and-choosing an appropriate SDK, but Apple decided that > availability annotations were good enough for developer purposes and moved > everything over to a single SDK only. this solution manifestly does work - since i use it - and the downstream projects like HB and macports, I thought recommended installing the CLT? .. however.... > > 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. > > Yeah, exactly. It’s not even going to be a matter of “what xcrun gives > them”, there will be a large enough number of macOS 14 systems with > developer tools but a macOS 15 SDK instead of a macOS 14 SDK. The SDKs are > going to be updated in the wild, I don’t think GCC has much of an option to > try to require that macOS 14 stick with that exact SDK. You need to be very careful here - because of the fixincludes we have not been able to drop yet (and some that will be very hard to drop because the SDKs are incompatible with legal C and C++) this does mean that the SDK that the compiler was built with does matter to them. In some cases, this means the compiler will not function with a different SDK from the one it was built with. I wish we could drop all the fixincludes - or find an alternate solution - but until then we're stuck with this. Anyway - the bottom line is that I agree with removing the legacy lib from macOS 14 (even if we do not completely agree on the reasons) .. will try to test & push the patch ASAP
(In reply to Iain Sandoe from comment #25) > 1. but you have identified that this cannot work when symbols are removed > from > a library .. as we see here Apple never really removes symbols that were ever a part of a public interface in an SDK, because it would create a compatibility problem. What happened here is a special case, because those symbols were never part of a public interface, and nobody ever referenced them. Except GCC did, which is why we’re here. But I’d be surprised if GCC ever used them in a meaningful way, since they never actually worked. (They were broken for 2 OS releases, and no-ops for the rest of time.) Had there ever been a public declaration, I don’t think Apple would have removed them. But the point stands that you’re inside of implementation territory, which Apple treats as private and owned end-to-end by them, and so GCC and even open-source LLVM are very much in “your mileage may vary” territory. > 2. That is definitely not the case for CLT - and I do not install Xcode (i > have > too many test boxes) > > $ ls /XC/14.1/CommandLineTools/SDKs/ > MacOSX.sdk MacOSX12.3.sdk MacOSX12.sdk MacOSX13.0.sdk MacOSX13.sdk > $ ls /XC/15.1b/CommandLineTools/SDKs/ > MacOSX.sdk MacOSX13.3.sdk MacOSX13.sdk MacOSX14.0.sdk MacOSX14.sdk Certainly, this is more about Xcode, not CLT. > > > 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). > > > > Infeasible, though. It’s been a very long time since Apple bundled more than > > one SDK per platform in Xcode. (The last time they did was Xcode 6.4 in > > 2015, with 10.9 and 10.10 SDKs, and some early Xcode 7.0 betas.) I really > > liked picking-and-choosing an appropriate SDK, but Apple decided that > > availability annotations were good enough for developer purposes and moved > > everything over to a single SDK only. > > this solution manifestly does work - since i use it - and the downstream > projects like HB and macports, I thought recommended installing the CLT? Some do, I don’t know about all. Nevertheless, I use MacPorts quite successfully on systems with only Xcode and no CLT. I don’t think it’d be prudent for GCC to require a particular flavor of OS toolchain and SDK installation, though. There will be machines in the wild with nothing but Xcode on them. > .. however.... > > > > 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. > > > > Yeah, exactly. It’s not even going to be a matter of “what xcrun gives > > them”, there will be a large enough number of macOS 14 systems with > > developer tools but a macOS 15 SDK instead of a macOS 14 SDK. The SDKs are > > going to be updated in the wild, I don’t think GCC has much of an option to > > try to require that macOS 14 stick with that exact SDK. > > You need to be very careful here - because of the fixincludes we have not > been able to drop yet (and some that will be very hard to drop because the > SDKs are incompatible with legal C and C++) this does mean that the SDK that > the compiler was built with does matter to them. In some cases, this means > the compiler will not function with a different SDK from the one it was > built with. > > I wish we could drop all the fixincludes - or find an alternate solution - > but until then we're stuck with this. Yes, it’s unfortunate, but you do need to treat a GCC installation as locked to the SDK that it was built against, precisely because of the fixincludes. > Anyway - the bottom line is that I agree with removing the legacy lib from > macOS 14 (even if we do not completely agree on the reasons) .. will try to > test & push the patch ASAP Thank you!
> Certainly, this is more about Xcode, not CLT. Not quite true, certainly not within MacPorts. See below. > > > > > 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). > > > > > > Infeasible, though. It’s been a very long time since Apple bundled more than > > > one SDK per platform in Xcode. (The last time they did was Xcode 6.4 in > > > 2015, with 10.9 and 10.10 SDKs, and some early Xcode 7.0 betas.) I really > > > liked picking-and-choosing an appropriate SDK, but Apple decided that > > > availability annotations were good enough for developer purposes and moved > > > everything over to a single SDK only. > > > > this solution manifestly does work - since i use it - and the downstream > > projects like HB and macports, I thought recommended installing the CLT? > > Some do, I don’t know about all. As far as we have a recommendation , it's to install *both* Xcode and the CLT. The reason being there are plenty of ports that are picky over which they build against. Many users attempt to only have the CLT installed, but they often run into problems with ports that simply will not build (or run) without a full Xcode installation. > > Nevertheless, I use MacPorts quite successfully on systems with only Xcode > and no CLT. > > I don’t think it’d be prudent for GCC to require a particular flavor of OS > toolchain and SDK installation, though. There will be machines in the wild > with nothing but Xcode on them. Within mMacPorts, as much as we have recommendations, on having Xcode and/or CLT installed, and the versions of them, doing so in practise is akin to cat herding. Futile in practise. We encounter all possible combinations of CLT and/or Xcode, and any of the possible versions any OS could have. Thats simply just the reality we have to deal with. When a user has both the CLT and Xcode installed, builds will tend to favour the CLT SDKs *not* the Xcode ones (this is why what the CLT supplies is very relevant). and just going back to the SDKs the CLT supply, yes, they supply multiple versions, but only two are actual SDKs, the rest just sym links. e.g. on macOS15 I see Larissa ~/Projects/MacPorts/ports > ls -lth /Library/Developer/CommandLineTools/SDKs total 0 lrwxr-xr-x 1 root wheel 14B 20 Sep 19:47 MacOSX.sdk -> MacOSX15.0.sdk lrwxr-xr-x 1 root wheel 14B 20 Sep 19:46 MacOSX14.sdk -> MacOSX14.5.sdk lrwxr-xr-x 1 root wheel 14B 20 Sep 19:46 MacOSX15.sdk -> MacOSX15.0.sdk drwxr-xr-x 7 root wheel 224B 21 Aug 16:15 MacOSX15.0.sdk drwxr-xr-x 7 root wheel 224B 30 Apr 23:16 MacOSX14.5.sdk The 'default' (as much as there is one) SDK, MacOSX.sdk, will always point to the newest. The above is with the Xcode 16 CLT version. If a user on macOS14 has the same installed, they will see the same, so their 'default' will also be the macOS15 version. Yes, you could say 'just always use the version one then, for your OS'. The issue there is controlling what all possible build systems do when presented with the above is another exercise in cat herding... The simple bottom line is as long as Apple is in the habit of making available to macOS(N-1) the Xcode version for macOSN, and the SDKs that go with that, we have to live with builds using them. Attempting to control that is just impractical.
Folks - we all want ponies... ... but remember this is a toolchain - it is quite complex; expecting any random permutation of things that you happen to choose to DTRT will probably disappoint you. Xcode does not attempt this with a team of people working on it for $dayjob - so we should really really not expect it for a 'team' of one working on it for $hobby. My thinking is that downstream is free to do whatever that they choose - but there has to be a limit on what we can support - all the permutations are simply not feasible ether to test or reason about. I want GCC to be an excellent compiler for Darwin - but that does mean being willing to operate within _some_ constraints.
Iains, I was not trying to suggest with my last post what you should support, that is entirely up to you and we are very grateful for what you do do. I was simply trying to expand on (and correct a bit) some of the points raised by Mark.
(In reply to Chris Jones from comment #29) > Iains, I was not trying to suggest with my last post what you should > support, that is entirely up to you and we are very grateful for what you do > do. > > I was simply trying to expand on (and correct a bit) some of the points > raised by Mark. Sure .. and if it appears I am grumpy, then apologies - that's not the intent. The bottom line is that we have to have some "supported" configuration set (and try to make that as wide as possible). I completely accept that end-users will do whatever they choose - but I think we all (at least those of us responsible for producing and distributing the toolchains) need to have position that "the following set of things, which are readily available on your platform work, correctly together - if you move outside of that you might be on your own". I have some ideas about how we can improve our lives re. the SDKs - but they need some moderate lifting coding-wise. Likewise we could isolate ourselves from dependency on Xcode for the assembler and linker - but also at the cost of extra maintenance (which, so far, we have chosen not to take on).
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:dd5b823ce238161156e7a4b6267bd30d7dde7c6b commit r15-3924-gdd5b823ce238161156e7a4b6267bd30d7dde7c6b Author: Mark Mentovai <mark@mentovai.com> Date: Tue Sep 24 16:11:14 2024 -0400 libgcc, Darwin: Don't build legacy libgcc_s.1 on macOS 14 [PR116809] d9cafa0c4f0a stopped building libgcc_s.1 on macOS >= 15, in part because that is required to bootstrap the compiler using the macOS 15 SDK. The macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. libgcc_s.1 can no longer be built on macOS 14 using Xcode 16 by the same logic that the previous change disabled it for macOS 15. PR target/116809 libgcc/ChangeLog: * config.host: Don't build legacy libgcc_s.1 on macOS 14. Signed-off-by: Mark Mentovai <mark@mentovai.com>
I am being asked (by build systems folks) to make it possible to build back to 10.13 with the current [XC 16] SDKs (which are supposed to support that - but do not include these symbols). This seems a reasonable request and I will test an updated patch.
The releases/gcc-14 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:cae584bddd0e348d9ac6f9bd917b47255a26458e commit r14-11709-gcae584bddd0e348d9ac6f9bd917b47255a26458e Author: Mark Mentovai <mark@mentovai.com> Date: Tue Sep 24 16:11:14 2024 -0400 libgcc, Darwin: Drop the legacy library build for macOS >= 10.12 [PR116809]. From macOSX15 SDK, the unwinder no longer exports some of the symbols used in that library which (a) causes bootstrap fail and (b) means that the legacy library is no longer useful. No open branch of GCC emits references to this library - and any already -built code that depends on the symbols would need rework anyway. We have been asked to extend this back to the earliest OS vesion supported by the SDK (10.12). PR target/116809 libgcc/ChangeLog: * config.host: Build legacy libgcc_s.1 on hosts before macOS 10.12. * config/i386/t-darwin: Remove reference to legacy libgcc_s.1 * config/rs6000/t-darwin: Likewise. * config/t-darwin-libgccs1: New file. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> (cherry picked from commit d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3)
The releases/gcc-13 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:3599245e4972b2322f75c909bc81961e41bc64ad commit r13-9719-g3599245e4972b2322f75c909bc81961e41bc64ad Author: Mark Mentovai <mark@mentovai.com> Date: Tue Sep 24 16:11:14 2024 -0400 libgcc, Darwin: Drop the legacy library build for macOS >= 10.12 [PR116809]. From macOSX15 SDK, the unwinder no longer exports some of the symbols used in that library which (a) causes bootstrap fail and (b) means that the legacy library is no longer useful. No open branch of GCC emits references to this library - and any already -built code that depends on the symbols would need rework anyway. We have been asked to extend this back to the earliest OS vesion supported by the SDK (10.12). PR target/116809 libgcc/ChangeLog: * config.host: Build legacy libgcc_s.1 on hosts before macOS 10.12. * config/i386/t-darwin: Remove reference to legacy libgcc_s.1 * config/rs6000/t-darwin: Likewise. * config/t-darwin-libgccs1: New file. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> (cherry picked from commit d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3)
The releases/gcc-12 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>: https://gcc.gnu.org/g:4c4135438a6b100f27968a3fda41e580dba61b52 commit r12-11247-g4c4135438a6b100f27968a3fda41e580dba61b52 Author: Mark Mentovai <mark@mentovai.com> Date: Tue Sep 24 16:11:14 2024 -0400 libgcc, Darwin: Drop the legacy library build for macOS >= 10.12 [PR116809]. From macOSX15 SDK, the unwinder no longer exports some of the symbols used in that library which (a) causes bootstrap fail and (b) means that the legacy library is no longer useful. No open branch of GCC emits references to this library - and any already -built code that depends on the symbols would need rework anyway. We have been asked to extend this back to the earliest OS vesion supported by the SDK (10.12). PR target/116809 libgcc/ChangeLog: * config.host: Build legacy libgcc_s.1 on hosts before macOS 10.12. * config/i386/t-darwin: Remove reference to legacy libgcc_s.1 * config/rs6000/t-darwin: Likewise. * config/t-darwin-libgccs1: New file. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> (cherry picked from commit d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3)
fixed on open branches