[MacPorts] #59157: clang-3.7 @3.7.1_5: cp: build/tools/clang/runtime/compiler-rt/clang_darwin/10.4/libcompiler_rt.a: No such file or directory

[MacPorts]

#59157: clang-3.7 @3.7.1_5: cp: build/tools/clang/runtime/compiler-
rt/clang_darwin/10.4/libcompiler_rt.a: No such file or directory
------------------------+----------------------
  Reporter:  Ionic      |      Owner:  jeremyhu
      Type:  defect     |     Status:  assigned
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.6.99
Resolution:             |   Keywords:
      Port:  clang-3.7  |
------------------------+----------------------

Comment (by Ionic):

 I think I understand what's happening there.

 `llvm-3.7.1.src/projects/compiler-rt/make/platform/clang_darwin.mk` is
 filtering out configs that don't have matching architectures:

 {{{
 # Remove empty configs if we end up dropping all the requested
 # archs for a particular config.
 $(foreach config,$(Configs),\
   $(if $(strip $(UniversalArchs.$(config))),,\
         $(call Set,Configs,$(filter-out $(config),$(Configs)))))
 }}}

 This evicts the `10.4` and `eprintf` configs, because...

 {{{
 UniversalArchs.eprintf :=
 UniversalArchs.10.4 :=
 }}}

 (i.e., both are empty)

 So far, so bad.

 But why are they empty? What value should they have instead?

 {{{
 UniversalArchs.eprintf := $(call CheckArches,i386,eprintf,$(OSX_SDK))
 UniversalArchs.10.4 := $(call CheckArches,ppc i386 x86_64,10.4,$(OSX_SDK))
 }}}

 Interesting. It looks like these variables should contain the listed
 arches if the compiler and requested SDK supports them.

 CheckArches is a pretty complicated shell command building a source file
 and parsing its output, but here's the other thing: it requires an SDK
 path to be passed as its third list parameter, and...

 {{{
 OSX_SDK :=
 }}}

 Whoops, that's one empty, so the compile step will never be executed - and
 all arches be dropped.

 Again, what SHOULD it be?

 {{{
 OSX_SDK := $(call XCRunSdkPath,macosx)
 }}}

 `XCRunSdkPath` is also a quite complex shell command, but it generally
 tries to execute `xcrun --sdk $foo.internal --show-sdk-path`, `xcrun --sdk
 $foo --show-sdk-path` or `xcodebuild -sdk $foo -version | sed ...` until
 one of the commands succeeds.

 I've tried making `make` print out the command output, but the result was
 bleak:

 {{{
 PRINT_XCRUN_INTERNAL := \
   $(shell \
     result="$$(xcrun --sdk macosx.internal --show-sdk-path)"; \
     echo $$result)

 PRINT_XCRUN := \
   $(shell \
     result="$$(xcrun --sdk macosx --show-sdk-path)"; \
     echo $$result)

 PRINT_XCODEBUILD := \
   $(shell \
     result="$$(xcodebuild -sdk macosx -version)"; \
     echo $$result)

 ---

 PRINT_XCRUN_INTERNAL :=
 PRINT_XCRUN :=
 PRINT_XCODEBUILD :=
 }}}

 ... and all of this is probably caused by

 {{{
 DEVELOPER_DIR='/Library/Developer/CommandLineTools'
 }}}

 ----

 This issue seems to be yet another incarnation of #58779.

 Check this:

 {{{
 % DEVELOPER_DIR=/Library/Developer/CommandLineTools xcrun --sdk macosx
 --show-sdk-path

 % xcrun --sdk macosx --show-sdk-path
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
 }}}

 It looks like we'll have to workaround this issue by setting `use_xcode
 yes` in the port for platforms that DO NOT ship SDKs as part of CLT.
 Otherwise clang and its components will not be able to find the SDK and
 fail in such a difficult to debug way.

-- 
Ticket URL: <https://trac.macports.org/ticket/59157#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS