how to replace llvm-3.2 with llvm-3.3?

[Ryan Schmidt]

Remember to Reply All when you reply, so that your reply goes to the mailing list too, not just to me.

On Jun 26, 2014, at 3:04 PM, Christopher David Ramos wrote:

> Thank you very much for your help, Ryan. You were concise and very clear.
> 
> I understand now how to obtain port maintainer contact info from the
> command line.
> 
> It seems to me that general procedure is as follows:
> 
> If I need a newer version of a port, yet am unable to uninstall the old
> version, I should first install the newer versions of said port's
> dependencies. Then I can uninstall the older versions of those
> dependencies and the older version of the port of interest.
> 
> I think I'm still "missing" sometimes as I had assumed that this sort of
> maintenance work was handled by macports whenever I did a "sudo port
> upgrade outdated".
> 
> If I'm mistaken, please disabuse me of any nonsense.
> 
> Oh, and just to be abundantly clear, your instructions worked pefectly.


Generally that's true. MacPorts will ensure that if you upgrade a port, its dependencies will be upgraded first, if needed.

However some software packages that we have in MacPorts, such as llvm and other compilers (clang, gcc), databases (mysql, postgresql, db), and languages (php, python, perl, ruby), are a little different because we actually have multiple ports for each software package, each at a different version, so that you can choose which version you want. You can even have multiple versions installed simultaneously. For example, some ports might require python27 while others need python34. No problem; both can be installed and used side-by-side.

And ports don't exist only so that other ports can use them; ports are also there so that they can be used directly. Some users may have written code that needs python26. Or llvm-3.2. Or be running a database on mysql55 and be unable to upgrade to mysql56 immediately for whatever reason. No problem; the user can stay on those older versions as long as they need to, and switch to the newer ports when they're ready.

Ports (like cctools and ld64) that use these types of ports (in this case llvm) typically offer variants to let you choose what version you want:

$ port variants ld64
ld64 has the variants:
   llvm29: Use llvm-2.9 for libLTO
     * conflicts with llvm30 llvm31 llvm32 llvm33 llvm34 llvm35
   llvm30: Use llvm-3.0 for libLTO
     * conflicts with llvm29 llvm31 llvm32 llvm33 llvm34 llvm35
   llvm31: Use llvm-3.1 for libLTO
     * conflicts with llvm29 llvm30 llvm32 llvm33 llvm34 llvm35
   llvm32: Use llvm-3.2 for libLTO
     * conflicts with llvm29 llvm30 llvm31 llvm33 llvm34 llvm35
   llvm33: Use llvm-3.3 for libLTO
     * conflicts with llvm29 llvm30 llvm31 llvm32 llvm34 llvm35
[+]llvm34: Use llvm-3.4 for libLTO
     * conflicts with llvm29 llvm30 llvm31 llvm32 llvm33 llvm35
   llvm35: Use llvm-3.5 for libLTO
     * conflicts with llvm29 llvm30 llvm31 llvm32 llvm33 llvm34
   universal: Build for multiple architectures

One of them will usually be selected by default, e.g. with ld64 today that's +llvm34, because llvm version 3.5 has not yet been released in a final version, but once it is, +llvm35 will become the default.

MacPorts preserves your variant selections across upgrades. So when you installed ld64 some time ago, +llvm32 was the default, and that selection has been preserved for you in upgrades ever since.

MacPorts does not currently differentiate between variants you selected deliberately and variants which were automatically selected because they were the default. There has been some talk about maybe changing that, so that automatically-selected variants are not remembered, so that new defaults will be automatically applied. But I don't think any code has been written to do that yet. So until then, you have to be aware of what variants are selected in your installed ports and occasionally reinstall them with newer variants, if that's what you want.