Compilers and Variants and Architectures Oh My!

[Jeremy Lavergne]

> Although I have read the page "Using the Right Compiler" this page
> does not actually provide any insight as to which compiler should be
> used to build the MacPorts tree, particularly on older systems with
> rather outdated system compilers.  It seems as if MacPorts prefers
> clang, but by default it uses your system's default clang. While this
> is probably best if you are running the latest XCode, this is clearly
> not optimal if you are limited to an older version of XCode.  Would it
> indeed be wise to install clang 3.2 or 3.3 and then set this to the
> default compiler for MacPorts?  If so, how does one set the default
> compiler in MacPorts?  Furthermore, would it be wise to build a
> bootstrap install of MacPorts to obtain the desired compiler, and then
> use this to build the primary MacPorts install?

The default compilers are listed here:
<https://trac.macports.org/browser/trunk/base/src/port1.0/portconfigure.tcl#L443>

Only 10.4 has an OS-specific check due to the differently-named SDK from Apple; everything else operates based on Xcode version.

You can override the defaults in a Portfile using whitelists and blacklists or you can edit the MacPorts source and build/install it. Just be mindful that running selfupdate may eventually replace what you've installed.

> Now onto Variants...  When I built Wine on my previous system, it
> seems as if every package used by Wine got recompiled as a +universal
> variant.  I assume this is because Wine only runs under i386 arch.  I
> noticed in several places it was suggested to make +universal the
> default variant on systems running 64-bit kernels, even aside from
> Wine.  Is this actually a good procedure?  It does seem to break some
> software, most notably msp430-gcc built outside of MacPorts, and the
> AVR tools within MacPorts.

You're right that +universal was triggered due to wine.

In this case it is needed to provide the default native architecture (x86_64) where available while providing a stack for the other architecture that wine needs (i386). You certainly can always build +universal anyways, but it tends to be a waste of space unless you know you'll need it.

Another option is changing the default architecture (build_arch in macports.conf) to i386. On Mac OS X 10.6 the default is x86_64 if the CPU supports it, i386 otherwise.

> Can someone explain how libraries are managed when compiled with
> +universal?  Does this build both architectures into a single library,
> or are multiple libraries created for each architecture?  What is the
> proper way to install packages like avr-binutils that do not have a
> +universal variant, when +universal is selected as a system default?

Yes, both architectures go into a single library.

If a package has its universal variant disabled there is likely some actual issue. All crossbinutils (e.g. avr-binutils) have their universal variants diabled.

Here's an example +universal library.
$ file libatk-1.0.0.dylib 
libatk-1.0.0.dylib: Mach-O fat file with 2 architectures: [ X86_64: Mach-O 64-bit x86_64 dynamically linked shared library ] [ I386: Mach-O i386 dynamically linked shared library ]

After installation, you can see what files were installed by a given port via `port contents PORTNAME`. Similarly, MacPorts can tell you what architectures were asked for during installation via `port -v installed [PORTNAME]`.