What's the reasoning behind using ld64 for gccXX?

[Jeremy Huddleston]

On Apr 18, 2012, at 19:48, Sean Farley wrote:

>> The main reason that it wasn't that way was because for quite some time the rest of the toolchain was just not as well maintained.  That's no longer the case, so now we can benefit from that work in other ports.  YAY!
>> 
>> Benefit 1 - Consistency across similar ports
>> clang-mp-* use MacPorts's ld64 to link.
>> apple-gcc-4.2 uses MacPorts ld64 to link and MacPorts cctools to assemble if they're installed (they're not a dependency because it would set up a dependency cycle)
>> gcc-mp-* should join the party.
> 
> Should? Why? They have been working perfectly fine, and if I recall
> correctly, there was a problem using ld64 with gcc 4.6 (but that could
> have due to other options such as --dynamic-strings)

What do you mean by that?  gcc 4.6 *WAS* using ld64 and still *IS* using ld64.  The difference is which ld64 is being used (the one from XCode or the one from MacPorts).  If some version of gcc has some issues with some version of ld64, that only supports the need to do this since we will now have control over the version of ld64 used.  The only place where ld64 wasn't being uses was Tiger, and with this change, now gccXX actually work on Tiger.

>> Benefit 2 - MacPorts philosophy
>> This helps isolate bugs due to different versions of XCode being installed in the same way we like to isolate bugs across OS version deltas by providing as much of the library stack as possible.
> 
> Please show a list of bugs this fixes.

Huh?  This is just how MacPorts is done, and always has been.  This is why we provide all of X11 libraries instead of using the system ones, like fink.  I'm not sure what bugs you're asking for.

>> Benefit 3 - Required on older OSs
>> On older OS versions which don't support newer XCode, they need newer versions of cctools and ld64 to even use recent compilers.
> 
> Which can easily be tested for. I figure, based on your recent
> commits, that you already have these ports installed but for most
> users this adds a ton of new ports that are really unnecessary.

I think you are misjudging "most users" ... I don't think "most users" actually give a hoot about the gcc ports or the clang ports.  They just care about wireshark, gimp, xchat, kde, or other such "user" applications.  gcc may be pulled in as a build dependency of some of those ports, and yeah, they'll need to build llvm for that.  If they don't like that, and they want to use as much of / as possible instead of ${prefix}, then there are certainly alternatives out there to explain to them why that is a bad idea...

> /usr/bin/ar and friends have been working fine, and more importantly,
> it's what the testers of gcc use.

Do they test every possible version from every XCode released?  I doubt it, and even if they did, so what?  This keeps us more consistent across different OS and XCode versions and limits the scope of what *WE* must support.

--Jeremy