Darwin, libgcc: Only build libemutls_w.a with shared

[zhaofengli]

This patch skips building libemutls_w.a if shared libraries are disabled, because libemutls_w.a depends on emutls_s.o.

[iains]

I understand the problem you are describing, but this patch cannot be the right solution (libemutls_w.a is a necessary component)

so that the solution needed is to adjust the dependencies for libemutls_w.a so that it depends on emutls_s.o for shared and emutls.o for non-shared.

Actually, for most Darwin/macOS cases, it makes no sense to --disable-shared, since macOS always uses PIC code (sole exception is -mdynamic-no-pic on earlier versions). So it does not make the code any smaller or faster to "--disable-shared".

[zhaofengli]

Thanks for the clarification! The downstream usecase in nixpkgs is to build a standalone version of libgcc from the gcc tree to simplify bootstrapping. If --enable-shared is used then libgcc_s.dylib is built against libc/libSystem which defeats the purpose. In practice this doesn't appear to be used much in the package collection.

Maybe @Ericson2314 have something to add? The context is https://github.com/NixOS/nixpkgs/pull/196565.

[iains]

I am a bit puzzled ..

All macOS user-space applications are built against libSystem.dylib (there is no such thing as a "static" user-space program) so that having libgcc_s.1{.1.}dylib built against it should make no difference?

What version of OSX / macOS are you targeting here? (there are some differences in deployment onto OSX 10.4/5/6 from 10.7+)

[iains]

We have recently fixed a long-term issue with libgcc by splitting the handling of the builtins, emulated TLS support and EH handling into separate parts.

libgcc.a contains the builtins (convenience library) libemutls_w.a contains a weak version of the emulated TLS support

libgcc_s.1.1.dylib contains a shared version of the builtins + the emulated TLS support.

There is an unwinder in libgcc_eh.a and libgcc_ehs.dylib (shared).

Those (unwinder libs) should almost never be used, since that defeats the ability to unwind through system libraries and they are no needed since the unwinder is supplied by /usr/lib/libgcc_s.1.dylib (10.4/5) or libSystem.dylib (10.6+)

---

We do build a libgcc_s.1.dylib (on powerpc and x86) which forwards libgcc_s.1.1.dylib and the unwinder, this is not needed for any new code built with current GCC, it is provided only as a compatibility library for existing exes.

(minor edits to clarify a couple of points)

[cooljeanius]

"This branch has conflicts that must be resolved" @zhaofengli, could you try resolving them please?

[iains]

"This branch has conflicts that must be resolved" Zhaofeng, could you try resolving them please?

I am still not clear about why this change would be needed - the questions posted above were not answered. In any event the PR is likely to need amendment.

[cooljeanius]

"This branch has conflicts that must be resolved" Zhaofeng, could you try resolving them please?

I am still not clear about why this change would be needed - the questions posted above were not answered. In any event the PR is likely to need amendment.

Yeah, I was hoping that by pinging @zhaofengli, I/we could get an update from him about the remaining issues with this PR, but, I guess no such luck... I'd say if we don't hear anything from him in like another 3 months or so, then I'd just close this.

[cooljeanius]

"This branch has conflicts that must be resolved" Zhaofeng, could you try resolving them please?

I am still not clear about why this change would be needed - the questions posted above were not answered. In any event the PR is likely to need amendment.

Yeah, I was hoping that by pinging @zhaofengli, I/we could get an update from him about the remaining issues with this PR, but, I guess no such luck... I'd say if we don't hear anything from him in like another 3 months or so, then I'd just close this.

OK so yeah, I think it's time to close this now.

[zhaofengli]

Sorry all, it's been a while and I've lost context on the PR. It's likely not needed and can be closed.