[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:  closed
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.1.3
Resolution:  wontfix       |   Keywords:  tiger
      Port:                |
---------------------------+----------------------
Changes (by mfeiri@…):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Replying to [comment:8 jeremyhu@…]:
 > Replying to [comment:7 mfeiri@…]:
 > > @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

 Ah, I didn't realize that the ability to cross compile ''for'' old systems
 implies usability of the new headers ''on'' the old systems. I'll give it
 a try when I have time. Although the prospect of backporting ppc support
 is still a concern... if I had any intention to fork xnu instead of just
 packaging it, I would have joined the PureDarwin project.


 > > 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.

 ACK

 > > 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)

 Well, my intention was exactly to provide the same versions as exist on
 the host, because my goal is to use MacPorts independent of Xcode. In any
 case, I understand your motivation and having matching headers in MacPorts
 now should be a useful starting point for further explorations. What
 concerns darwin8 support, i'm sorry, but there is little more I can do.

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