Opened 7 months ago

Closed 6 months ago

#60196 closed defect (fixed)

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

Reported by: ryandesign (Ryan Schmidt) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: elcapitan Cc: larryv (Lawrence Velázquez), kencu (Ken), someuser12, dbl001 (dbl), m214089, pdvnl
Port: clang-3.7

Description

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

Change History (25)

comment:1 Changed 7 months ago by kencu (Ken)

Well that's disappointing.

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

comment:2 Changed 7 months ago by ryandesign (Ryan 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.)

comment:3 Changed 7 months ago by 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...

comment:4 Changed 7 months ago by someuser12

Cc: someuser12 added

comment:5 Changed 7 months ago by 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?

Last edited 7 months ago by kencu (Ken) (previous) (diff)

comment:6 Changed 7 months ago by kencu (Ken)

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

now to fix the test...

comment:7 Changed 7 months ago by 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 ...

Last edited 7 months ago by kencu (Ken) (previous) (diff)

comment:8 Changed 7 months ago by kencu (Ken)

Cc: dbl001 added

comment:9 Changed 7 months ago by ryandesign (Ryan Schmidt)

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

comment:10 Changed 7 months ago by m214089

Cc: m214089 added

comment:11 Changed 7 months ago by 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...

Last edited 7 months ago by kencu (Ken) (previous) (diff)

comment:12 Changed 7 months ago by ryandesign (Ryan Schmidt)

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

comment:13 Changed 7 months ago by pdvnl

Cc: pdvnl added

comment:14 Changed 7 months ago by 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

comment:15 Changed 7 months ago by kencu (Ken)

In a754c7e1041bbebc7eacbe343db9a42a8178566d/macports-ports (master):

clang-3.7: needs use_xcode to build

see #59677
see #58779
see #60196

comment:16 Changed 7 months ago by 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.

comment:17 Changed 7 months ago by pdvnl

it works.

thanks!

comment:18 Changed 7 months ago by ryandesign (Ryan 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)

comment:19 Changed 7 months ago by 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

comment:20 Changed 7 months ago by ryandesign (Ryan Schmidt)

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

comment:21 Changed 7 months ago by 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.

comment:22 in reply to:  21 Changed 7 months ago by ryandesign (Ryan 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.

comment:23 Changed 7 months ago by 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.

comment:24 Changed 6 months ago by 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.

comment:25 Changed 6 months ago by kencu (Ken)

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.