clang-3.7: libcompiler_rt.a: No such file or directory

[ryandesign (Ryan Carsten Schmidt)]

​clang-3.7 does not build on elcapitan citing several errors like this:

cp: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/eprintf/libcompiler_rt.a: No such file or directory
cp: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/10.4/libcompiler_rt.a: No such file or directory
cp: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/cc_kext/libcompiler_rt.a: No such file or directory
cp: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/osx/libcompiler_rt.a: No such file or directory
cp: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/ubsan_osx_dynamic/libcompiler_rt.dylib: No such file or directory
cp: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/profile_osx/libcompiler_rt.a: No such file or directory
cp: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/runtime/compiler-rt/clang_darwin/asan_osx_dynamic/libcompiler_rt.dylib: No such file or directory

[kencu (Ken)]

Well that's disappointing.

This [611ec1e42ccff6647c552ce3e2483e357b37d15e/macports-ports] was supposed to fix that.

[ryandesign (Ryan Carsten Schmidt)]

FYI that commit is from Feb 22 and the log I linked to was from Jan 27, because it was the one linked from ​the port page and because it was a self-contained log for just that port. But what prompted me to file this ticket was ​this log from today of the same failure; the log is just much larger because many other outdated ports were built first. (The 10.11 builder has been offline since Feb 19 so there are many outdated ports to be built. It is working through the backlog and all outdated rdeps get included in a build.)

[kencu (Ken)]

OK. Not sure then if it's still fixed or broken. Ionic did a mega-analysis and I followed his lead on that fix, TBH, as per one of the tickets.

But I did just see that error building clang-3.7 on 10.4 Tiger Intel, so I guess I can work on it too...

[kencu (Ken)]

On 10.11, there is no MacOSX10.11.sdk. There is a MacOSX10.12.sdk instead, which is a symlink to MacOSX.sdk.

I think that must be why this is failing.

So either the test I'm using to decide whether to set use_xcode yes is not working for that reason, or it is working but things are going wonky because there is no MacOSX10.11.sdk despite use_xcode yes.

Sigh. How to sort this out with minimial mess? Maybe another example of why this :

if ${configure.sdkroot} eq ""} {
    set configure.sdkroot "/"
}

should be in base?

[kencu (Ken)]

it's the test. Just forcing use_xcode yes without the test works fine....

now to fix the test...

[kencu (Ken)]

Now why does this happen, I wonder, on two of my 10.11 systems ?

$ ls -la /Library/Developer/CommandLineTools/SDKs
total 8
drwxr-xr-x  4 root  wheel  136  1 Jul  2017 .
drwxr-xr-x  5 root  admin  170  1 Jul  2017 ..
drwxr-xr-x  5 root  wheel  170 17 Sep  2017 MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10  1 Jul  2017 MacOSX10.12.sdk -> MacOSX.sdk

$ ls -la /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
total 0
drwxr-xr-x  3 root  wheel  102  3 Mar  2016 .
drwxr-xr-x  5 root  wheel  170 26 Apr  2016 ..
drwxr-xr-x  5 root  wheel  170 20 Oct  2020 MacOSX10.11.sdk

and the other:

$ ls -la /Library/Developer/CommandLineTools/SDKs
total 8
drwxr-xr-x  4 root  wheel  136 13 Jan  2018 .
drwxr-xr-x  5 root  admin  170 13 Jan  2018 ..
drwxr-xr-x  5 root  wheel  170 17 Sep  2017 MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10 13 Jan  2018 MacOSX10.12.sdk -> MacOSX.sdk

$ ls -la /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
total 0
drwxr-xr-x  3 root  wheel  102  4 May  2016 .
drwxr-xr-x  5 root  wheel  170  4 May  2016 ..
drwxr-xr-x  5 root  wheel  170  4 May  2016 MacOSX10.11.sdk

No wonder this is not working right ...

[ryandesign (Ryan Carsten Schmidt)]

On the elcapitan buildbot worker, both of those locations contain only MacOSX10.12.sdk (symlink) and MacOSX.sdk (directory). Xcode 8.2.1.

[kencu (Ken)]

I upgraded (finally) my 10.11 system to Xcode 8.2.1 (perhaps port diagnose should help report the wrong xcode versions for older systems? ).

Anyway, clang-3.7 does build on 10.11 with Xcode 8.2.1 if you set use_xcode yes, however compiler_rt somehow stupidly winds up choosing the iphoneOS SDK to build against (how?? -- I have seen this happen before in another scenario -- trying to recall the exact port and system). That SDK has only *.tbd linker files in it, so you have to update ld64 to ld64-latest, which you should do anyway on 10.11, but it is a few manual steps:

sudo port -v install ld64-latest
sudo port -v -n upgrade --enforce-variants ld64 -ld64_274

and then it builds.

That's workable, a bit ugly.

On 10.4 I just hack in the SDK I want clang-3.7 to use instead of letting it get caught up in this mess of SDK-finding that so often goes wrong...

What port wants clang-3.7 on 10.11 anyway? That's kinda silly right there, to be honest. Perhaps we should just fix *that* problem and forget this mess...

[ryandesign (Ryan Carsten Schmidt)]

Seems like I've seen zillions of build failures on 10.11 due to clang-3.7.

[pdvnl]

i did

sudo port -v install ld64-latest
sudo port -v -n upgrade --enforce-variants ld64 -ld64_274

and it still failed to build:

grep '\] Error' /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/clang-3.7/main.log
:info:build make[3]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.10.4.a] Error 1
:info:build make[3]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.osx.a] Error 1
:info:build make[3]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.asan_osx_dynamic.dylib] Error 1
:info:build make[3]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.cc_kext.a] Error 1
:info:build make[3]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.profile_osx.a] Error 1
:info:build make[3]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib] Error 1
:info:build make[3]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.7/clang-3.7/work/build/Release+Debug/lib/clang/3.7.1/lib/darwin/libclang_rt.eprintf.a] Error 1
:info:build make[2]: *** [compiler-rt/.makeall] Error 2
:info:build make[1]: *** [all] Error 1
:info:build make: *** [all] Error 1

[kencu (Ken)]

In a754c7e1041bbebc7eacbe343db9a42a8178566d/macports-ports (master):

clang-3.7: needs use_xcode to build

see #59677
see #58779
see #60196

[kencu (Ken)]

Let that commit propogate through for a bit, then update your portfiles, clean clang-3.7, and try it then please. Here's hoping this finally clears this up (at least for folks that have updated to ld64-latest).:

sudo port clean clang-3.7
sudo port selfupdate
sudo port -v install clang-3.7

Please report back.

[pdvnl]

it works.

thanks!

[ryandesign (Ryan Carsten Schmidt)]

Then ​the next problem is:

ld: unexpected token: !tapi-tbd-v2 file '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib/libc++.tbd' for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[kencu (Ken)]

Yes - I haven't found an automatic way of getting around the fact that (I think all of) the 8.2.1 SDKs have TAPI libs in them and so need the current ld64-latest...

sudo port -v install ld64-latest
sudo port -v -n upgrade --enforce-variants ld64 -ld64_274

[ryandesign (Ryan Carsten Schmidt)]

Right but this failure happens on the buildbot. It has to be fully automated.

[kencu (Ken)]

Yes, indeed. Here I am happy to have some input from you, Josh, and Marcus.

We do need some kind of mechanism to make these situations work. The two most pressing ones I know of so far are the libcxx without +emulated_tls bootstrap issue on < 10.7, and this ld64 issue.

Chris suggested an ld64 wrapper that calls the newest one that is available. The only issue with that is that it would be hard to know, in the end, which ld64 was ever invoked when someone opens a ticket.

I don't completely understand how the variants are propagated -- maybe you can help me with that. For example, on Tiger, you first install {apple-gcc-4.2 +bootstrap and then once that is installed, you run sudo port -v install apple-gcc-4.2 and it somehow reinstalls itself without the bootstrap variant, which surprised me. I thought port would see the previous +bootstrap variant enabled and would try to keep that variant enabled.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

I don't completely understand how the variants are propagated -- maybe you can help me with that. For example, on Tiger, you first install {apple-gcc-4.2 +bootstrap and then once that is installed, you run sudo port -v install apple-gcc-4.2 and it somehow reinstalls itself without the bootstrap variant, which surprised me. I thought port would see the previous +bootstrap variant enabled and would try to keep that variant enabled.

Variant selections are preserved when you upgrade, not when you install.

This apple-gcc42 +bootstrap variant situation isn't great either. There should be a separate apple-gcc42-bootstrap (sub)port instead.

[kencu (Ken)]

For a 1-step process, as it appears that we need ld4-latest to build clang-3.7, we would have to build ld64-latest with clang-3.4 to do this reliably. That means building libtapi with clang-3.4 on many systems to make this work. I'll have to eee if that is possible.

[kencu (Ken)]

I had time to do some further investigating here, and I believe that a workable solution to the ld64 / TAPI situation on 10.11 has now been found, by using the ld64 from Xcode as the default.

[e3d8e509fd8eb639810377e7ed851e6975fa926b/macports-ports] should do it, I hope. It works nicely here.