What's the reasoning behind using ld64 for gccXX?

[Jeremy Huddleston]

On Apr 18, 2012, at 20:47, Sean Farley wrote:

>> 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.
> 
> You wrote "This helps isolate bugs",

Sorry, language alludes me sometimes.  What I meant to say is that this helps isolate us from bugs related to differences in XCode or OS versions.

> to which I ask, "Which bugs?"

This is preventative.

> My point is that you're being unnecessarily pedantic here.

You're free to have that view, but I've already laid out the case FOR.  Your only point AGAINST is the desire to not build more ports, and that's not much, especially given the benefits.

>> 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...
> 
> You are missing the point. You are asking the user to now build *two*
> compilers.

No.  They're not building a second compiler.  They're bringing in ld64 (a linker) and cctools (as, ar, ranlib, etc), both of which need use llvm.

> MacPorts depends on Xcode and xcode provides ld64 (along
> with a compiler sans fortran to compile said gcc port). The most
> common case I've seen is a user that wants some kind of fortran
> compiler.

Well they can certainly get a fortran compiler from gcc46, and it will use OUR ld64 and OUR cctools which we have control over and can provide bug fixes for and properly support in ways that we can't possibly support bits in /usr.

>> 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.
> 
> Again, you're being overly pedantic and have not provided a valid
> reason as of yet.

I gave you a bunch, which I'll summarize again:
1) Consistency with apple-gcc42, clang-*
2) Consistency with MacPorts philosophy
3) Required for usage on older OSs
4) Easier for us to support

> Why even have Xcode as a requirement then if you're
> not going to use it?

1) It's a great default for people who don't care about messing with compiler toolchains.
2) It's required to bootstrap the process of using a MP toolchain for those who want to go down that road.

---

We ran into the same complaints when I fixed the xorg libraries in MacPorts and started updating ports to depend on them.  People started complaining that they had to build all these new ports when things were "just fine" the way they were, but in the end it was the right solution.  Tiger through Mountain Lion can all use the (mostly) identical X11 server and clients.

Yes, you need to take 20 more minutes to build llvm, ld64, and cctools, but guess what, it's worth it in the end.

If you want to build your own gcc which *DOESN'T* use MacPorts, you're free to use fink, homebrew, or just build it yourself.

--Jeremy