Using apple-gcc42 on Tiger

[Jeremy Huddleston]

The main reason for this is not so much a bug in the compiler, but rather the linker.  On Tiger, the default linker comes from cctools and is quite archaic.  It is very finicky about ordering on the command line, and it has just been easier to "fix" this by using our newer linker than /usr/bin/ld.  The way I've chosen to use our linker is by using apple-gcc42.  When apple-gcc42 is installed, it will prefer to use our ld64 if installed and fall back on the host ld if it is not installed.  On Leopard, the default linker is ld64, so the host gcc-4.0 works fine in that scenario because it has the newer linker.

Parenthetically, I would like to have a runtime dependency on ld64 in apple-gcc42, but doing so introduces a dependency cycle since ld64 requires llvm-3.0 which requires apple-gcc42 to build +universal on Leopard and Tiger.  This seemed like the logical place to break the cycle since the others are build and link dependencies and this is just a runtime dependency.

The most common symptom is a list of unsatisfied symbols at link time.  Here is an example from the latest version of libquicktime without the change:

/bin/sh ../libtool --tag=CC   --mode=link /usr/bin/gcc-4.0 -DLOCALE_DIR=\"/opt/local/share/locale\" -pipe -O2 -arch i386  -finline-functions -Wall -Winline -Wmissing-declarations -Wdeclaration-after-statement -fvisibility=hidden  -L/opt/local/lib -arch i386 -o qtinfo qtinfo.o common.o ../src/libquicktime.la -lm -lz -ldl 
libtool: link: /usr/bin/gcc-4.0 -DLOCALE_DIR=\"/opt/local/share/locale\" -pipe -O2 -arch i386 -finline-functions -Wall -Winline -Wmissing-declarations -Wdeclaration-after-statement -fvisibility=hidden -arch i386 -o .libs/qtinfo qtinfo.o common.o  -L/opt/local/lib ../src/.libs/libquicktime.dylib /opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -lc -lm -lz -ldl
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:
_quicktime_close
_quicktime_open
_lqt_channel_to_string
_lqt_chroma_placement_to_string
_lqt_colormodel_to_string
_lqt_file_type_to_string
_lqt_frame_duration
_lqt_get_album
_lqt_get_artist
_lqt_get_audio_language
_lqt_get_author
_lqt_get_channel_setup
_lqt_get_chroma_placement
_lqt_get_cmodel
_lqt_get_comment
_lqt_get_file_type
_lqt_get_genre
_lqt_get_interlace_mode
_lqt_get_pixel_aspect
_lqt_get_sample_format
_lqt_get_text_language
_lqt_get_track
_lqt_get_wav_id
_lqt_has_timecode_track
_lqt_interlace_mode_to_string
_lqt_is_avi
_lqt_is_chapter_track
_lqt_sample_format_to_string
_lqt_text_samples
_lqt_text_time_scale
_lqt_text_tracks
_lqt_video_time_scale
_quicktime_audio_bits
_quicktime_audio_compressor
_quicktime_audio_length
_quicktime_audio_tracks
_quicktime_frame_rate
_quicktime_get_copyright
_quicktime_get_info
_quicktime_get_name
_quicktime_sample_rate
_quicktime_supported_audio
_quicktime_supported_video
_quicktime_track_channels
_quicktime_video_compressor
_quicktime_video_depth
_quicktime_video_height
_quicktime_video_length
_quicktime_video_tracks
_quicktime_video_width
collect2: ld returned 1 exit status
make[3]: *** [qtinfo] Error 1
make[3]: *** Waiting for unfinished jobs....


A recent xorg-server build failure was also related (but a bit more cryptic due to other noise), which got me into investigating this:
https://trac.macports.org/ticket/33818


On Apr 7, 2012, at 9:53 PM, Ryan Schmidt <ryandesign at macports.org> wrote:

> I see lots of revisions like r91601 being committed where the apple-gcc42 port is being used as the compiler on Tiger to work around problems with the old compilers in Tiger's Xcode.
> 
> Could this be added to the PortfileRecipes wiki page? Specifically I'm trying to figure out how to know if a particular Tiger build failure would benefit from this change -- what is(are) the signature error message(s) that would indicate apple-gcc42 should be employed?
> 
> I'm also curious why Leopards gcc-4.0 would nevertheless still be suitable. Or would it be better to just say if compiler is gcc-4.0, use gcc-4.2 or apple-gcc42?