[MacPorts] #38684: apple-gcc42 can no longer be built on Tiger

[MacPorts]

#38684: apple-gcc42 can no longer be built on Tiger
---------------------------+----------------------
  Reporter:  ryandesign@…  |      Owner:  mfeiri@…
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.1.3
Resolution:                |   Keywords:  tiger
      Port:                |
---------------------------+----------------------

Comment (by jeremyhu@…):

 Replying to [comment:7 mfeiri@…]:
 > The problem here really is xnu-headers. I do make an effort to support
 as many old platforms as I can, but darwin9/ppc is the oldest one I have.
 I'll happily accept patches to support darwin8 in xnu-headers, but I can
 not do/test that myself.
 >
 > @jeremyhu: Is "newer userland headers [...] are still compatible with
 older systems" the official position of Apple?

 Yes, and it always has been (up to intentionally removed support for old
 architectures, hence why I suggested grabbing the ppc headers from SN xnu
 if they were removed).

 This is why we say to always use the newest SDK with -mmacosx-version-
 min=10.X

 > That would be nice!! I simply do not have the resources to do the
 necessary validation tests myself and I certainly don't have resources to
 do validation of a backport to an unsupported architecture. So, I just
 closely follow upstream.
 >
 > I would have expected to hear criticism suggesting the other extreme:
 Follow Apple's example and have multiple distinct SDKs, e.g.
 ${prefix}/SDKs/MacOSX10.8.sdk. Any thoughts about that?

 No, that will land you in even more trouble.  You'd have to take care of
 making a sparse SDK which would be a real PITA and not really worth it.

 > Anyway, in r104991 I've just removed the minimum os version checks from
 all my ports, so anyone can now check if darwin8 can use the darwin12
 versions of the headers ports.

 Why not just use the darwin12 version in all places?  Using the same
 version as exists on the host is pointless (since it's already on the
 host).  The big win of having it in MacPorts is that you can get newer
 headers in order to build newer tools (eg, due toe updated CPU_SUBTYPE_
 definitions in mach/machine.h)

-- 
Ticket URL: <https://trac.macports.org/ticket/38684#comment:8>
MacPorts <http://www.macports.org/>
Ports system for OS X