llvm / clang / cctools / ld64 version consistency question

[Mihai Moldovan]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160728/0ccfec4f/attachment.sig>