On 27.07.2016 03:22 PM, Ken Cunningham wrote: > Having run into an unexpected problem with clang-3.7 segfaulting not long ago > after a 3.7 minor version update, and then an interesting libLTO incorrect > "version error" when I tried to upgrade the compiler chain from clang-3.7 to > clang-3.8, I'd like to have a slightly better understanding of how these tools > fit together.
This is a bug and not intended behavior. I have created a new ticket #51929 for this, including a description of what is wrong.[0] > There is a port select mechanism for clang, and a port select mechanism for > llvm. But would it be fair to say you would always do both of them together, > ie > if you're switching to clang-3.8, you'll also need to switch to llvm-3.8? This > seems pretty obvious, and I always do switch both when I do it. Should the > port > select mechanism just do that automatically for both if you ask it do it for > one? In theory, yes, but: MacPorts by default uses the compiler as installed by Xcode by default and if possible (GCC on older systems, clang on newer systems) with the built-in tools (assembler, linker, ...) Some ports though override this, because they need specific (newer) versions or fixed compiler versions in general. Hence, ports can blacklist compilers (which means that the first available compiler from a fallback list will be used - with prior installation if necessary) or even select specific compilers through whitelisting explicitly. Using port select to create symlinks only changed ${prefix}/bin/clang (and other stuff) to the selected variant. Nothing within MacPorts itself is relying on it, so whether a particular version is selected or not is not relevant to MacPorts - it's merely a convenience-provider for users, so that executing "clang" will automatically use a specific selected version iff ${prefix}/bin is within the user's PATH environment variable. > Also, cctools and ld64 also have a specific variant for each version of llvm, > it > appears from the following command. The MacPorts-provided compilers (gcc-mp-*, clang-mp-*) (to my knowledge) all use the linker as installed by ld64 or ld64-${version} ports. (Actually, ld64 only creates wrapper-symlinks more or less to a specific ld64 version.) The ld64-${version} subports compile the linker (ld) with the compiler selected via one of the provided variants - on 10.9+ the default variant is llvm38, so libraries from that LLVM version will be linked and *should* be used at run time. Due to the bug you already noticed, they aren't correctly used currently. We'll need to get this fixed. cctools is similar, although cctools generally only ships (important) support binaries - not really interesting in regard to our linking problem at hand. > sudo port -v -n upgrade --enforce-variants cctools -llvm33 -llvm34 +llvm37 > configure.compiler=macports-clang-3.7 > sudo port -v upgrade --enforce-variants ld64 -llvm33 -llvm34 +llvm37 > configure.compiler=macports-clang-3.7 You shouldn't need to override configure.compiler. (Unless you're following "LibcxxOnOlderSystems", of course, in that case please skip this part of my answer or take it with a grain of salt.) `sudo port -svt install --unrequested ld64 cctools -llvm38+llvm37` should work around the mentioned problem for now (+ leave the other build around, which can easily be re-activated later.) > So is it also the case that if you're switching clang versions (and then llvm > versions) you need to run commands like the following to bring your cctools > and > ld64 variants into sync? According to what I tried to explain above, no. :) > And finally, for those of us who have installed libc++ on older systems, just > to > clarify that libc++ is a fixed entity, and it does not change or need to > change > with any of the above - build it once, install it, and leave it alone, > basically? Define older systems. There's a wiki page for that[1]. In general, if you switched to libc++ once, you won't be able to go back without scrapping your complete prefix first. And naturally, you should never delete libc++. It might chance, but backwards compatibility should be a thing, hopefully. Generally, I'd say you don't have to cater to it manually anymore after the initial prefix "conversion". Mihai [0] https://trac.macports.org/ticket/51929 [1] https://trac.macports.org/wiki/LibcxxOnOlderSystems
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev