> 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]`. _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
