Opened 4 years ago

Closed 4 years ago

#60196 closed defect (fixed)

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

Reported by: ryandesign (Ryan Carsten 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 4 years ago by kencu (Ken)

Well that's disappointing.

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

comment:2 Changed 4 years ago by 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.)

comment:3 Changed 4 years 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 4 years ago by someuser12

Cc: someuser12 added

comment:5 Changed 4 years 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 4 years ago by kencu (Ken) (previous) (diff)

comment:6 Changed 4 years 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 4 years 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

No wonder this is not working right ...

Version 1, edited 4 years ago by kencu (Ken) (previous) (next) (diff)

comment:8 Changed 4 years ago by kencu (Ken)

Cc: dbl001 added

comment:9 Changed 4 years ago by 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.

comment:10 Changed 4 years ago by m214089

Cc: m214089 added

comment:11 Changed 4 years 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 4 years ago by kencu (Ken) (previous) (diff)

comment:12 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

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

comment:13 Changed 4 years ago by pdvnl

Cc: pdvnl added

comment:14 Changed 4 years 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 4 years 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 4 years 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 4 years ago by pdvnl

it works.

thanks!

comment:18 Changed 4 years ago by 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)

comment:19 Changed 4 years 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 4 years ago by ryandesign (Ryan Carsten Schmidt)

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

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

comment:23 Changed 4 years 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 4 years 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 4 years ago by kencu (Ken)

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