Default compiler changes for Leopard and Tiger

[Ryan Schmidt]

In r92109 [1] Jeremy H changed the default compiler for Leopard. He and I have been discussing this possibility privately, along with changing the default compiler for Tiger, and he has already tested a large chunk of ports on Tiger and Leopard built in this new way, so I wanted to talk publicly now about why we think this is a good idea.

When Tiger was introduced, the Xcode default compiler changed to gcc 4.0 (and MacPorts followed this change), which caused some problems for some ports that had been written assuming gcc 3.3. By the time Leopard was released, most software had adjusted to gcc 4.0, and gcc 4.0 remained the default command-line compiler on Leopard as well. But on Snow Leopard the default changed to gcc 4.2, and as the years go by and fewer developers test on Leopard and Tiger, more and more ports are failing to build on gcc 4.0 because they were only tested on newer gcc. Note also that gcc 4.2 is already the default compiler on Leopard when creating a project in Xcode. In some ports we have added "platform darwin 9" blocks to change the compiler to gcc 4.2 on Leopard to work around such problems (examples: cairo, libmemcached, mesa) but there are probably more ports that are failing to build on Leopard that would benefit from this, and I fear the list of gcc-4.0-incompatible software will only continue to grow. We therefore propose (and r92109 implements) changing the default compiler for Leopard from gcc 4.0 to gcc 4.2.

The same problem exists on Tiger but its Xcode doesn't include a copy of gcc 4.2 so to implement this proposal there we have to use the apple-gcc42 port instead. What remains to be done here is to find a way to make the apple-gcc42 port a dependency of all ports on Tiger, in a more rebust way than simply setting a default value for depends_lib or depends_build, since most ports set (i.e. overwrite) the dependency variables rather than append to them. Another possibility would be to just issue an error message on Tiger if apple-gcc42 is not installed, but that wouldn't be quite as nice.

On Tiger the additional issue is the linker. Some of you may remember builds of various ports failing on Tiger due to missing symbols, and the workaround being to manually add various "-l" flags (examples: pcre, qt4-mac, taglib). There are other issues with the old linker that can't be fixed so easily (for example, apple-gcc42 fails to build on Tiger with the old linker). We can fix these problems by making ports always use the new ld64 linker on Tiger.

Jeremy H has been manually adding "platform darwin 8" blocks adding apple-gcc42 and ld64 dependencies to several ports. Having this functionality in base would allow us to simplify those ports again. It would also allow us to simplify pcre, qt4-mac, taglib and other ports currently manually adding "-l" flags on Tiger. It would also fix several ports for which we had not already gotten around to adding "-l" flags on Tiger.

One of the ports that seems to need apple-gcc42 / ld64 on Tiger but that hasn't had that block added yet is glib2 [2]. Adding it there would mean that most Tiger users would have to install these ports anyway, since glib2 is a dependency of pkgconfig, and pkgconfig is a dependency of most ports. So at that point we may as well make all ports use the new compiler and linker.

Jeremy H mentioned that using apple-gcc42 / ld64 on Tiger has a viral quality:

On Apr 12, 2012, at 11:42, Jeremy Huddleston wrote:

> If you link a port with ld64, then anything that links against it will also need ld64.

So this again speaks for changing the default compiler globally on Tiger and not on an individual port basis. It also speaks for rebuilding all ports with the new compiler. That's one of the reasons why I proposed [3] that MacPorts record in its registry and in archive names not only the port name, version, revision, epoch, variants, architectures and OS version, but also the compiler used, and offer to users (via "port outdated") to rebuild them when any of these changes.


[1] https://trac.macports.org/changeset/92109

[2] https://trac.macports.org/ticket/33988

[3] http://lists.macosforge.org/pipermail/macports-dev/2012-April/018689.html