MacPorts wants to install apple-gcc42 on 10.6 all of a sudden?

[Ned Deily]

In article <0307D314-6374-4FBB-AC6D-7E229A5BA026 at gmail.com>,
 "Rene J.V. Bertin" <rjvbertin at gmail.com> wrote:
> On Apr 22, 2013, at 21:23, Ned Deily wrote: 
> > That's correct.  xcode-select sets the defaults that are used by several 
> > other build tools, primarily xcodebuild and xcrun but it has no effect 
> > on what is installed in system locations.  If you allowed the Xcode 4.2 
> Yes. xcode-select is just a very basic script that updates a file, from which 
> in turn other scripts read the prefix to prepend to /usr/bin (etc) when 
> invoking the necessary commands. Just an extra indirection.

I'm not sure I understand what you are saying there but, in general, the 
whole point of using xcode-select and its related tools is to avoid 
having to install anything in /usr/bin et al.  They provide a mechanism 
to use the Xcode-supplied build tools, like clang or gcc-4.2, from an 
Xcode-specific location, either in the equivalent of /Developer (or 
wherever one has installed the instance of Xcode) or from within the 
Xcode.app bundle (for current Xcode 4's on 10.7+).  xcrun and friends 
allow you to create a build process (Makefile or script) that has no 
dependencies on anything being installed outside of Xcode.  I'm not 
aware of any third-party Makefiles that take direct advantage of that 
(I'm sure there are some) but, in many cases, it isn't *too* difficult 
to modify an autoconf-based build process to use it.  But, unless one 
has some need to support multiple Xcode tools chains simultaneously on 
the same machine, it's much simpler to also have Xcode install the build 
tools in their customary system locations (/usr/bin).  For current 
versions of Xcode, that option is not on by default, as Xcode.app itself 
does not need them to be installed when building Xcode-based projects.   
The defaults are such that Apple is assuming that developers are going 
to be building code primarily within Xcode, not by calling compilers 
directly.

> > Installer to install the command tools package (I'm not sure what the 
> > package name is for Xcode 4.2), you would need to re-install the 3.2.6 
> > UNIX Development package using the Xcode 3.2.6 Installer to get the 
> > proper executables and header files installed in /usr/bin, /usr/include, 
> > /System/Frameworks, et al.  First, though, you should uninstall the 4.2 
> > command tools by using the uninstaller script from the Xcode 4.2 
> > /Developer directory:
> 
> I think this applies only if you installed 4.2 to its default location. I 
> haven't had to do any of this - my Unix toolchain still uses the 3.2.6 
> executables if I refer to the default tools, but Xcode 4.2 uses its own 
> versions from within its IDE. Exactly as I had hoped.

It doesn't matter where Xcode itself is located since, essentially, 
Xcode.app does not depend on installing anything into system locations 
like /usr.  What matters is whether a particular Xcode's command line 
tools package has been installed  which makes the Xcode-provided build 
tools available from the command line in the system locations.   Since 
each command line tools package installs to fixed locations (e.g. 
/usr/bin/cc etc), only one command line tools package can be installed 
at one time, and a given command line tool pacakge can only be installed 
on a specific OS X release.  In other words, you could install Xcode 
3.2.6 on OS X 10.8 along with Xcode 4.6.2 but, the command line tools 
package for 3.2.6 can only be installed on OS X 10.6.  To use the 3.2.6 
compilers from the command line on 10.8, you would need to use xcrun or 
construct its equivalent.

> I must admit I hadn't thought about universal build implications of choosing 
> a non-Apple compiler. Curiously, the first port of which I installed a 
> universal variant was ffmpeg, and that package cannot (easily) be built as 
> universal by simply specifying the desired architectures. I've presumed that 
> Macports followed the same approach as Xcode, i.e. build each architecture in 
> parallel and then pull in (lipo) the resulting binaries. More cumbersome, but 
> if the build engine allows to do this it does have advantages (finer control 
> over compiler options). And of course it works with any compiler that 
> supports the desired architectures!

Many third-party packages can be build universal out-of-the-box or with 
trivial modifications just by adding -arch arguments, thanks to the 
integration of the whole multiple builds and lipo process under the 
covers in the Apple-supplied compiler drivers.  One has to be careful of 
autoconf-based builds that make decisions based on ./configure time 
tests that are run only in the default architecture.  Those kinds of 
problems can be difficult to foresee.  It can be safer to run the whole 
process build process in parallel, rather than depending on the compiler 
driver magic, but even then there is no guarantee that the built product 
isn't making some arch-dependent run time decisions incorrectly.
 
> Out of curiosity: is gcc-4.2 the last compiler for which Apple made it 
> possible to build it on systems where you cannot obtain the binaries directly 
> from Apple? If so, are there any plans to provide ports of those compilers 
> (supposing there's any interest to that ... introducing features like ARC 
> which aren't supported by the runtime isn't particularly useful ...)

I'm not sure I understand what you are asking here.  I believe Apple 
decided to stop using gcc for its build systems for a couple of reasons: 
one, the change in licensing of newer versions of gcc to GPL-3 and, two, 
the growing importance of other CPU architectures to Apple, i.e. ARM, 
for iOS-based systems.  Thus they have put a lot of support into the 
LLVM project and, as of OS X 10.8, use clang to build OS X.  While they 
still have been shipping a legacy version of LLVM with a gcc 4.2 
front-end (and that is not the same compiler as the non-LLVM gcc-4.2 
included with Xcode 3.2.6), Apple announced that the recent Xcode 4.6 
release would be the last major release to include it.   So, if you want 
or need a gcc beyond Apple's gcc-4.2, you need to supply it yourself, 
for instance, by using one of the MacPorts-supplied gcc ports, i.e. port 
install gcc49.

-- 
 Ned Deily,
 nad at acm.org