#53931 closed defect (fixed)
clang's ld doesn't recognise "-lto_library" flag on 10.6
Reported by: | mojca (Mojca Miklavec) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | snowleopard | Cc: | jmroot (Joshua Root), dliessi (Davide Liessi), mascguy (Christopher Nielsen) |
Port: | clang-3.9 clang-4.0 llvm-3.9 llvm-4.0 |
Description
See this failed build for example. This is clang 3.9 failing to build llvm 4.0 on Snow Leopard:
/opt/local/bin/clang-mp-3.9 -pipe -Os -arch x86_64 -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names CMakeFiles/cmTC_25d4d.dir/testCCompiler.c.o -o cmTC_25d4d ld: library not found for -lto_library clang: error: linker command failed with exit code 1 (use -v to see invocation)
Joshua suggested:
Looks like
ld
is interpreting-lto_library
as-l
with a library name ofto_library
. No LTO support I guess.
I didn't test clang 3.8, but clang 3.7 works on 10.6 and clang 4.0 works on 10.7.
Change History (26)
comment:1 Changed 8 years ago by kencu (Ken)
comment:2 Changed 8 years ago by kencu (Ken)
mmm. probably not that, I guess, looking at the logs. libc++ is installed on 10.6 as a dependency during the build, and the build is configured to use it.
could this be relevant:
sh: pkg-config: command not found
comment:3 Changed 8 years ago by mojca (Mojca Miklavec)
It might be worth fixing, but it's definitely not the source of the problem.
comment:4 Changed 8 years ago by michael-o0
Would like input as well, it makes 3.9 unusable:
$ cat main.c #include <stdio.h> int main (int argc, char **argv) { printf("Hello\n"); return (0); } $ clang -v main.c clang version 3.9.1 (tags/RELEASE_391/final) Target: x86_64-apple-darwin10.8.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-3.9/bin "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -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 136 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1 -fdebug-compilation-dir /Users/m -ferror-limit 19 -fmessage-length 194 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/MT/MTiEpDjxGZOrGNo6rf-bGk+++TI/-Tmp-/main-ceb961.o -x c main.c clang -cc1 version 3.9.1 based upon LLVM 3.9.1 default target x86_64-apple-darwin10.8.0 ignoring nonexistent directory "/usr/local/include" #include "..." search starts here: #include <...> search starts here: /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/opt/local/libexec/llvm-3.9/bin/ld" -demangle -lto_library /opt/local/libexec/llvm-3.9/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o a.out -lcrt1.10.6.o /var/folders/MT/MTiEpDjxGZOrGNo6rf-bGk+++TI/-Tmp-/main-ceb961.o -lSystem /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1/lib/darwin/libclang_rt.osx.a ld: library not found for -lto_library clang: error: linker command failed with exit code 1 (use -v to see invocation) $ ls -al /opt/local/libexec/llvm-3.9/lib/libLTO.dylib -rwxr-xr-x 1 root admin 179892 Apr 19 17:07 /opt/local/libexec/llvm-3.9/lib/libLTO.dylib $ uname -a Darwin m.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
comment:5 Changed 8 years ago by kencu (Ken)
I have a slightly older clang-3.9.0 installed on 10.6, and it works fine. I pegged it at that version a few months ago, and pegged ld64 at that time too.
It looks like the /opt/local/libexec/llvm-3.9/bin/ld
phase of my build does not include an -lto_library
flag, whereas yours does. I'm not certain whether that request comes in from clang-3.9, or whether it's a function of ld64 (both of which have been updated several times since Dec 2016 when I pegged them last). But at least it's a clue, I hope.
$ clang --version clang version 3.9.0 (tags/RELEASE_390/final) Target: x86_64-apple-darwin10.8.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-3.9/bin $ clang -v main.c clang version 3.9.0 (tags/RELEASE_390/final) Target: x86_64-apple-darwin10.8.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-3.9/bin "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -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 264.3.102 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0 -fdebug-compilation-dir /Users/cunningh/Desktop/test -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/main-6686d8.o -x c main.c clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target x86_64-apple-darwin10.8.0 #include "..." search starts here: #include <...> search starts here: /usr/local/include /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/opt/local/libexec/llvm-3.9/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o a.out -lcrt1.10.6.o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/main-6686d8.o -lSystem /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.osx.a
comment:6 Changed 8 years ago by kencu (Ken)
again, with clang-3.9.0 and ld64, this time forcing LTO -- works.
$ clang -v -flto main.c clang version 3.9.0 (tags/RELEASE_390/final) Target: x86_64-apple-darwin10.8.0 Thread model: posix InstalledDir: /opt/local/libexec/llvm-3.9/bin "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-llvm-bc -flto -disable-free -disable-llvm-verifier -discard-value-names -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 264.3.102 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0 -fdebug-compilation-dir /Users/cunningh/Desktop/test -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/main-9db6ce.o -x c main.c clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target x86_64-apple-darwin10.8.0 #include "..." search starts here: #include <...> search starts here: /usr/local/include /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/opt/local/libexec/llvm-3.9/bin/ld" -demangle -object_path_lto /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/cc-9ece95.o -lto_library /opt/local/libexec/llvm-3.9/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o a.out -lcrt1.10.6.o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/main-9db6ce.o -lSystem /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.osx.a
$ ./a.out Hello
$ port -v installed | grep ld64 ld64 @2_0+universal-ld64_127-ld64_136-ld64_236-ld64_97 (active) platform='darwin 10' archs='i386 x86_64' date='2016-09-01T23:15:02-0700' ld64-136 @136_9+llvm39-llvm34 (active) platform='darwin 10' archs='x86_64' date='2016-12-21T10:45:57-0800' ld64-latest @274.1_1+llvm39+universal-llvm34 (active) platform='darwin 10' archs='i386 x86_64' date='2016-12-21T15:41:59-0800' $ port -v installed | grep clang-3.9 clang-3.9 @3.9.0_2+analyzer (active) platform='darwin 10' archs='x86_64' date='2016-12-21T04:54:30-0800'
comment:7 Changed 8 years ago by kencu (Ken)
This commit <https://reviews.llvm.org/D25932> would appear to explain why LTO is now automatically invoked on newer llvm versions, I think. It would appear to have become the default to invoke LTO when this commit was included in an llvm version release -- presumably after 3.9.0 and before 3.9.1 as yours invokes it automatically whereas mine does not.
So I guess the remaining question is why ld64 finds the LTO library without apparent troubles on my machine, but not on your machine...
And I notice my build has -object_path_lto
specified, but yours does not seem to have that ....
comment:8 Changed 8 years ago by kencu (Ken)
With this commit <https://github.com/macports/macports-ports/commit/393e9ab3d71d2e79d553e1373257f80b93d7c268> Jeremy changed the default ld64 on snowleopard back to ld64-127.
I'm running ld64-136 on this snowleopard machine.
comment:9 Changed 8 years ago by kencu (Ken)
I notice libLTO.dylib is linked into the /opt/local/libexec/ld64/ld like so, on my current machine...
cmd LC_LOAD_DYLIB cmdsize 64 name @executable_path/../lib/libLTO.dylib (offset 24) time stamp 2 Wed Dec 31 16:00:02 1969 current version 3.9.0 compatibility version 1.0.0
comment:10 follow-up: 12 Changed 8 years ago by kencu (Ken)
OK - looking at the source code for the two versions of ld64 <https://opensource.apple.com/tarballs/ld64/> , the issue is that ld64-127 does not understand -lto_library
whereas ld64-136 does understand it.
So it appears to be the rollback to ld64-127 on snowleopard that has caused this (together with the fact that it's now the default to invoke it).
Jeremy's obviously very busy these days - but presumably he had a reason to roll back ld64 on snowleopard -- I just don't know what it is.
As part of the LibcxxOnOlderSystems instructions, ld64 is meant to be upgraded to ld64_136 on snowleopard, it appears:
sudo port -v upgrade --enforce-variants ld64 -ld64_97 -ld64_127 -ld64_236 sudo port -v deactivate ld64_127
comment:11 Changed 8 years ago by mojca (Mojca Miklavec)
Thanks a lot for the analysis. These are the two relevant commits:
- 393e9ab3
ld64: Default to +ld64_127 on Snow Leopard
- 87e7b2fc
ld64-136: Mark port obsolete. Users should be able to use ld64-127, ld64-236, or ld64-latest instead.
I initially tried
sudo port -v install -ld64_127
which failed due to defunct clang 3.9. As expected and consistent with the fact that we don't have the package for ld64-latest
for 10.6 from the buildbot. Note that ld64-latest
needs libc++
.
Then I installed
sudo port install ld64 +ld64_236 -ld64_127
and after that clang-3.9
was working again and I was able to install ld64-latest
as well.
Jeremy definitely changed the default variant because he wanted to retire the port ld64-136
. Why he decided to go to ld64-127
is something I don't know. Does ld64-236
build on 10.6 out of the box without having ld64-127
installed first? If so, we should definitely make ld64-236
the default for 10.6. If not, we need some additional trickery, but we really need to fix this.
comment:12 Changed 8 years ago by mojca (Mojca Miklavec)
Replying to kencu:
As part of the LibcxxOnOlderSystems instructions, ld64 is meant to be upgraded to ld64_136 on snowleopard, it appears:
sudo port -v upgrade --enforce-variants ld64 -ld64_97 -ld64_127 -ld64_236 sudo port -v deactivate ld64_127
No, ld64_136
no longer exists, so this would be ld64_latest
.
comment:13 Changed 8 years ago by kencu (Ken)
Fresh install of macports-2.4.1 on 10.6 with stock Xcode 3.2.6. No modifications made.
Version: 3.2 (10A432) Location: /Developer Applications: Xcode: 3.2 (1610) Interface Builder: 3.2 (732) Instruments: 2.0 (1095) Dashcode: 3.0 (328) SDKs: Mac OS X: 10.4: (8S2167) 10.5: (9J61) 10.6: (10A432)
sudo port -v install ld64-236
downloads a prebuilt binary and installs it, with some deps.
If you uninstall all ports then try the build again, forcing a build of ld64-236, it fails on snowleopard with this old familiar error:
$ port -v installed No ports are installed.
$ sudo port -v build ld64-236 ---> Computing dependencies for ld64-236............................. The following dependencies will be installed: bzip2 cctools clang-3.4 clang_select db48 expat gdbm gettext ld64 ld64-127 libedit libffi libiconv libmacho-headers libxml2 llvm-3.4 llvm_select ncurses openssl perl5 perl5.24 python27 python2_select python_select readline sqlite3 xz zlib Continue? [Y/n]: Y
/opt/local/bin/clang++-mp-3.4 -Os -Os -stdlib=libstdc++ -stdlib=libstdc++ -arch x86_64 -I/opt/local/libexec/llvm-3.4/include -DLTO_SUPPORT -Isrc/abstraction -Isrc/ld -Isrc/ld/parsers -I/opt/local/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_ld64/ld64-236/work/dyld-421.2/include -c -o src/ld/passes/branch_island.o src/ld/passes/branch_island.cpp In file included from src/ld/parsers/opaque_section_file.cpp:26: In file included from /usr/include/c++/4.2.1/vector:65: /usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found #include <bits/c++config.h> ^ In file included from src/ld/parsers/macho_dylib_file.cpp:34: In file included from /usr/include/c++/4.2.1/vector:65: /usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found #include <bits/c++config.h> ^ In file included from src/ld/passes/branch_island.cpp:32: In file included from /usr/include/c++/4.2.1/vector:65: /usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found #include <bits/c++config.h> ^ In file included from src/other/dyldinfo.cpp:34: In file included from /usr/include/c++/4.2.1/vector:65: /usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found #include <bits/c++config.h> ^ In file included from src/ld/parsers/archive_file.cpp:32: In file included from /usr/include/c++/4.2.1/vector:65: /usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found #include <bits/c++config.h> ...
which is fixed as usual by adding this bit into the Portfile in the ld64-236 section:
configure.cppflags-append -I/usr/include/c++/4.2.1/i686-apple-darwin10
and then ld64-236 builds through to completion, with a few warnings, and installs OK. In the end, here is what you're left with:
$ port -v installed | grep ld64 ld64 @3_0+ld64_127 (active) platform='darwin 10' archs='x86_64' date='2017-04-22T11:24:34-0700' ld64-127 @127.2_14+llvm34 (active) platform='darwin 10' archs='x86_64' date='2017-04-22T11:24:32-0700' ld64-236 @236.3_7+llvm34 (active) platform='darwin 10' archs='x86_64' date='2017-04-22T12:08:21-0700'
comment:14 follow-up: 15 Changed 8 years ago by mojca (Mojca Miklavec)
I don't understand the "fixed as usual" bit (I'm not familiar with this kind of a fix, but I'm not a regular user of 10.6).
But that indeed means that there is a bit of a bootstrapping problem at the moment and we would run into problems if we simply changed the default version without changing anything else (installing the binary "doesn't count").
What would be the best/proper fix?
comment:15 Changed 8 years ago by kencu (Ken)
Replying to mojca:
I don't understand the "fixed as usual" bit (I'm not familiar with this kind of a fix, but I'm not a regular user of 10.6).
What I mean is that it's a bug we had worked on before in clang, a couple of times in my case, like this similar ticket you reported before 50845, and reported upstream by Jeremy https://bugs.llvm.org//show_bug.cgi?id=30858
But that indeed means that there is a bit of a bootstrapping problem at the moment and we would run into problems if we simply changed the default version without changing anything else (installing the binary "doesn't count").
I'm not sure why I'm seeing that bits/c++config.h issue again on this machine. I'll boot into a different MacPro I have that is also running 10.6 and build everything including all the deps from source, and see if it still happens.
What would be the best/proper fix?
comment:16 follow-up: 17 Changed 8 years ago by kencu (Ken)
I tried this with a fresh 10.6 VM, with basic Xcode 3.2. I did not see the bits/c++config.h
issue with this clean new system, so that must be something specific about the older 10.6 system that I will need to clean up.
First I tried changing the default ld64 to ld64-236 in the ld64 Portfile, but ld64-236 has a dependency on clang-3.4 to build, and clang-3.4 had a dependency on ld64 to build, so ld64-236 cannot be the default on 10.6.
Leaving the default ld64 as ld64-127 on 10.6, clang-3.4 will successfully build, and then you can use that to build ld64-236. ld64-236 or newer is needed to successfully run clang-3.9 with LTO support, as above.
So the simple step to enable 10.6 to run clang-3.9 is to first run sudo port -v install ld64-236
, which will in fact build through to completion on an unmodified 10.6 system.
ld64-latest has an amazing amount of build deps on 10.6, including llvm/clang 3.7, 3.8, AND 3.9, and I didn't start that build process running but I see no reason why it shouldn't complete once started.
is it possible to set something like ld64-236 or newer
as runtime dependency for clang-3.9?
comment:17 Changed 8 years ago by mojca (Mojca Miklavec)
Replying to kencu:
First I tried changing the default ld64 to ld64-236 in the ld64 Portfile, but ld64-236 has a dependency on clang-3.4 to build, and clang-3.4 had a dependency on ld64 to build, so ld64-236 cannot be the default on 10.6.
OK, that's what I suspected.
So the simple step to enable 10.6 to run clang-3.9 is to first run
sudo port -v install ld64-236
, which will in fact build through to completion on an unmodified 10.6 system.ld64-latest has an amazing amount of build deps on 10.6, including llvm/clang 3.7, 3.8, AND 3.9, and I didn't start that build process running but I see no reason why it shouldn't complete once started.
I suspect the large number of dependencies is due to trying to avoid dependency cycles.
is it possible to set something like
ld64-236 or newer
as runtime dependency for clang-3.9?
What I didn't test yet is whether it's enough to have ld64-236
installed or whether you actually need ld64 +ld64_236
. If it's enough to just install ld64-236
, I would indeed try adding that as a runtime dependency to clang 3.9. What I'm not sure about is whether it's possible to define "one or the other" as a runtime dependency in a way that won't kill us in cycles.
I feel like we need some better way to handle circular dependencies in cases when a compiler can build a newer version of itself.
comment:18 Changed 8 years ago by dliessi (Davide Liessi)
Cc: | dliessi added |
---|
comment:20 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)
clang seems at first glance to be doing the right thing here:
unsigned Version[5] = {0, 0, 0, 0, 0}; if (Arg *A = Args.getLastArg(options::OPT_mlinker_version_EQ)) { if (!Driver::GetReleaseVersion(A->getValue(), Version)) D.Diag(diag::err_drv_invalid_version_number) << A->getAsString(Args); } ... // Use -lto_library option to specify the libLTO.dylib path. Try to find // it in clang installed libraries. ld64 will only look at this argument // when it actually uses LTO, so libLTO.dylib only needs to exist at link // time if ld64 decides that it needs to use LTO. // Since this is passed unconditionally, ld64 will never look for libLTO.dylib // next to it. That's ok since ld64 using a libLTO.dylib not matching the // clang version won't work anyways. if (Version[0] >= 133) { // Search for libLTO in <InstalledDir>/../lib/libLTO.dylib StringRef P = llvm::sys::path::parent_path(D.Dir); SmallString<128> LibLTOPath(P); llvm::sys::path::append(LibLTOPath, "lib"); llvm::sys::path::append(LibLTOPath, "libLTO.dylib"); CmdArgs.push_back("-lto_library"); CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath)); }
And in the -v
output pasted above, I see -target-linker-version 136
being passed to clang, so the issue is that it thinks the linker is a newer version than it really is.
comment:21 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)
And the default for that should be set to the version of ld64 that was present at build time:
// Add a default value of -mlinker-version=, if one was given and the user // didn't specify one. #if defined(HOST_LINK_VERSION) if (!Args.hasArg(options::OPT_mlinker_version_EQ) && strlen(HOST_LINK_VERSION) > 0) { DAL->AddJoinedArg(0, Opts->getOption(options::OPT_mlinker_version_EQ), HOST_LINK_VERSION); DAL->getLastArg(options::OPT_mlinker_version_EQ)->claim(); } #endif
So this should be fixed by just revbumping the clang ports to rebuild with an updated HOST_LINK_VERSION.
comment:22 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:23 follow-up: 24 Changed 7 years ago by kencu (Ken)
Jeremy - the revbump might work but I don't think so - but I was too verbose above.
Short short short answer is ld64-127 (the current 10.6 default ld64) doesn't understand the flag -lto-library
. And clang-3.9.1 uses this by default.
I had ld64-136 installed previously (before the regression).
comment:24 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to kencu:
Jeremy - the revbump might work but I don't think so - but I was too verbose above.
Short short short answer is ld64-127 (the current 10.6 default ld64) doesn't understand the flag
-lto-library
. And clang-3.9.1 uses this by default.
No. clang-3.9.1 uses it if the value of -mlinker-version= is >= 133, and if -mlinker-version= is not passed in explicitly, it uses the version of ld that was present at build time.
I had ld64-136 installed previously (before the regression).
Exactly. clang-3.9 was built when ld64-136 was active. When it was downgraded to 127, you hit this problem because clang assumed it had version 136.
Revbumping forces a rebuild with ld64-127 active and thus clang-3.9 won't pass it on such installs.
comment:25 Changed 7 years ago by kencu (Ken)
I get it now. I should have read through comment:21 more carefully. Thanks.
comment:26 Changed 4 years ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
This is very weird.
I wonder if this is related to clang 3.9 defaulting to libstdc++ now, and not finding the libc++ environment on 10.6 (Marcus' changes for cxx11)...