clang-mp-3.7 and MACOSX_DEPLOYMENT_TARGET=10.3 do not mix

[jhi]

I have the latest macports clang 3.7 on the latest Yosemite or 10.10 (not yet El Capitan or 10.11), and the XCode 7.0.1 Command Line Tools installed.

Originally this failure came from trying to compile Perl, but I managed to reduce it to simply to the below-demonstrated problem, no Perl source needed: the macports clang doesn't work with the MACOSX_DEPLOYMENT_TARGET (​https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html) as opposed to the system clang, or the macports clang withOUT the MACOSX_DEPLOYMENT_TARGET.

I also show below the find outputs for the libgcc_s both in the XCode and under /opt/local/lib

% cat main.c
int main() {
  return 0;
}

% env MACOSX_DEPLOYMENT_TARGET=10.3 clang-mp-3.7 -o main main.c
ld: library not found for -lgcc_s.10.4
clang: error: linker command failed with exit code 1 (use -v to see invocation)

% env MACOSX_DEPLOYMENT_TARGET=10.3 /usr/bin/clang -o main main.c          

% env clang-mp-3.7 -o main main.c                       

% clang-mp-3.7 -v
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-apple-darwin14.5.0

% /usr/bin/clang -v
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

% env MACOSX_DEPLOYMENT_TARGET=10.3 clang-mp-3.7 -v -o main main.c
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
 "/opt/local/libexec/llvm-3.7/bin/clang" -cc1 -triple x86_64-apple-macosx10.3.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 242 -v -dwarf-column-info -resource-dir /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.0 -fdebug-compilation-dir /Users/jhi -ferror-limit 19 -fmessage-length 80 -mstackrealign -fblocks -fblocks-runtime-optional -fobjc-runtime=macosx-10.3.0 -fobjc-dispatch-method=non-legacy -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -o /var/folders/yg/hdcrkqfx5cgc80b9zgbhnw_h0000gn/T/main-86350b.o -x c main.c
clang -cc1 version 3.7.0 based upon LLVM 3.7.0 default target x86_64-apple-darwin14.5.0
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-3.7/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.3.0 -o main -lcrt1.o /var/folders/yg/hdcrkqfx5cgc80b9zgbhnw_h0000gn/T/main-86350b.o -lSystem -lgcc_s.10.4 /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.0/lib/darwin/libclang_rt.10.4.a
ld: library not found for -lgcc_s.10.4
clang: error: linker command failed with exit code 1 (use -v to see invocation)

% find /Applications/Xcode.app -name 'libgcc_s*'
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/libgcc_s.1.tbd
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libgcc_s.1.tbd
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libgcc_s.10.4.tbd
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libgcc_s.10.5.tbd

% find /opt/local/lib -name 'libgcc_s*'                 
/opt/local/lib/gcc43/libgcc_s.1.dylib
/opt/local/lib/gcc43/libgcc_s.10.4.dylib
/opt/local/lib/gcc43/libgcc_s.10.5.dylib
/opt/local/lib/gcc43/libgcc_s_ppc64.1.dylib
/opt/local/lib/gcc43/libgcc_s_x86_64.1.dylib
/opt/local/lib/gcc44/libgcc_s.1.dylib
/opt/local/lib/gcc44/libgcc_s.10.4.dylib
/opt/local/lib/gcc44/libgcc_s.10.5.dylib
/opt/local/lib/gcc44/libgcc_s_ppc64.1.dylib
/opt/local/lib/gcc44/libgcc_s_x86_64.1.dylib
/opt/local/lib/gcc45/libgcc_s.1.dylib
/opt/local/lib/gcc45/libgcc_s_ppc64.1.dylib
/opt/local/lib/gcc45/libgcc_s_x86_64.1.dylib
/opt/local/lib/gcc46/libgcc_s.1.dylib
/opt/local/lib/gcc46/libgcc_s_ppc64.1.dylib
/opt/local/lib/gcc46/libgcc_s_x86_64.1.dylib
/opt/local/lib/gcc47/libgcc_s.1.dylib
/opt/local/lib/gcc47/libgcc_s_ppc64.1.dylib
/opt/local/lib/gcc47/libgcc_s_x86_64.1.dylib
/opt/local/lib/gcc48/libgcc_s.1.dylib
/opt/local/lib/gcc48/libgcc_s_ppc64.1.dylib
/opt/local/lib/gcc48/libgcc_s_x86_64.1.dylib
/opt/local/lib/gcc49/libgcc_s.1.dylib
/opt/local/lib/gcc49/libgcc_s_ppc64.1.dylib
/opt/local/lib/gcc49/libgcc_s_x86_64.1.dylib
/opt/local/lib/gcc5/libgcc_s.1.dylib
/opt/local/lib/gcc5/libgcc_s_ppc64.1.dylib
/opt/local/lib/gcc5/libgcc_s_x86_64.1.dylib
/opt/local/lib/libgcc/libgcc_s.1.dylib

% 

[ryandesign (Ryan Carsten Schmidt)]

I think this is the problem where you need to reinstall the ld64 port with the +ld64_xcode variant ("sudo port install ld64 +ld64_xcode") because earlier versions of ld64 don't understand the changes that were made in Xcode 7.

But why are you setting MACOSX_DEPLOYMENT_TARGET to 10.3 when you're compiling for Intel? There were never any Intel Macs running Mac OS X 10.3.

[jeremyhu (Jeremy Huddleston Sequoia)]

This has nothing to do with the deployment target. This has to do with the text based stubs support.

Use the +ld64_xcode variant of ld64 to get this to link for now. +ld64_latest will support text based stubs once opensource.apple.com drops an updated ld64 from Xcode 7 which we can pull in.

Why are you using such an old deployment target. We didn't even have intel support until 10.4.x

[jhi]

This has nothing to do with the deployment target. This has to do with the text based stubs support.

Well, the deployment target is how the error became visible, as you can see from my example. Are you saying the clang-mp-3.7 was just lucky to work (to compile and link) when being compiled without the deployment target?

I think this is the problem where you need to reinstall the ld64 port with the +ld64_xcode variant ("sudo port install ld64 +ld64_xcode") because earlier versions of ld64 don't understand the changes that were made in Xcode 7.

Use the +ld64_xcode variant of ld64 to get this to link for now. +ld64_latest will support text based stubs once opensource.apple.com drops an updated ld64 from Xcode 7 which we can pull in.

Umm, thanks, never heard of this ld64 thing. ld64_xcode? ld64_latest? Is there some documentation for the use of these options? (I'd like to amend the Perl build instructions, if there is).

For example, from the above it sounds like one should normally use +ld64_xcode ... exactly when? Always?

But you are also saying that this is a transient failure, that +ld64_latest will eventually understand XCode 7?

But why are you setting MACOSX_DEPLOYMENT_TARGET to 10.3 when you're compiling for Intel? There were never any Intel Macs running Mac OS X 10.3.

Why are you using such an old deployment target. We didn't even have intel support until 10.4.x

This is actually an open question in the Perl project, if you have feedback/opinions on that, it would be great.

We know that the 10.3 target is getting a little bit old... but we are a little bit cautious over dropping the support for older OS X-es. That is, if a Perl would be compiled now without a deployment target (defaulting to the compiling OS X), how bad would it be if run in older OS X-es?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jhi@…:

This has nothing to do with the deployment target. This has to do with the text based stubs support.

Well, the deployment target is how the error became visible, as you can see from my example. Are you saying the clang-mp-3.7 was just lucky to work (to compile and link) when being compiled without the deployment target?

No, it doesn't have to do with luck. It has to do with how the compiler runtime was delivered in older OS versions. Setting the older deployment target causes a link against libgcc_s.10.4. It's that linking that is the problem, because the linker doesn't know how to use the tbd.

Use the +ld64_xcode variant of ld64 to get this to link for now. +ld64_latest will support text based stubs once opensource.apple.com drops an updated ld64 from Xcode 7 which we can pull in.

Umm, thanks, never heard of this ld64 thing. ld64_xcode? ld64_latest? Is there some documentation for the use of these options? (I'd like to amend the Perl build instructions, if there is).

ld64 is the linker. You can use variants to choose what the default linker is. +ld64_latest should be preferred in most cases, but there is lag after Apple releases Xcode versions before we can update ld64-latest to the newest version, so ld64-xcode may be newer during that period.

For example, from the above it sounds like one should normally use +ld64_xcode ... exactly when? Always?

Preferibly never. It was added specifically for this exact problem to give users of Xcode 7 a workaround.

But you are also saying that this is a transient failure, that +ld64_latest will eventually understand XCode 7?

Yes.

But why are you setting MACOSX_DEPLOYMENT_TARGET to 10.3 when you're compiling for Intel? There were never any Intel Macs running Mac OS X 10.3.

Why are you using such an old deployment target. We didn't even have intel support until 10.4.x

This is actually an open question in the Perl project, if you have feedback/opinions on that, it would be great.

We know that the 10.3 target is getting a little bit old... but we are a little bit cautious over dropping the support for older OS X-es. That is, if a Perl would be compiled now without a deployment target (defaulting to the compiling OS X), how bad would it be if run in older OS X-es?

If you really want to support all systems, setting it 10.4 should suffice.

If you want to cover the 99.9% case, setting it to 10.6 should suffice.

10.8 and 10.9 as minimum requirements are starting to be come more popular as well, but the reasons for that probably don't impact perl too much. You may, however, want to consider 10.7 because I brought in a good portion of SUSv4 updates, some Libc API extensions from FreeBSD, NetBSD RBTrees, and other various Libc niceties.

[mojca (Mojca Miklavec)]

A similar report in #51980.

[mojca (Mojca Miklavec)]

Cc Me!