Compilers and Variants and Architectures Oh My!
jeremy at lavergne.gotdns.org
Sun Mar 24 11:53:40 PDT 2013
> 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:
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]`.
More information about the macports-users