apple-gcc42 can no longer be built on Tiger

[ryandesign (Ryan Carsten Schmidt)]

Many ports now cannot be built with gcc-4.0 and so need to build with apple-gcc42 on Tiger.

apple-gcc42 depends on cctools.

As of r104906 cctools depends on xnu-headers.

xnu-headers depends on dtrace.

dtrace says it requires OS X 10.5 or later.

[cooljeanius (Eric Gallager)]

Perhaps xnu-headers' dependency on dtrace could only be required on 10.5+?

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

Also I'd cc mfeiri@macports on this considering he's the maintainer for xnu-headers and dtrace.

[jeremyhu (Jeremy Huddleston Sequoia)]

Plus xnu-headers is installing old xnu headers on older systems rather than newer userland headers (which are still compatible with older systems).

​mfeiri should update xnu-headers to always just install the latest headers. There may be a need to fetch additional headers from an older release for removed architectures, but other than that, you should just always be using the latest headers.

[jeremyhu (Jeremy Huddleston Sequoia)]

Cc Me!

[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? 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?

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.

[jeremyhu (Jeremy Huddleston Sequoia)]

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

[mfeiri]

Replying to jeremyhu@…:

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

[cooljeanius (Eric Gallager)]

Replying to mfeiri@…:

Replying to jeremyhu@…:

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

You should join the PureDarwin project anyway! I'm sure they'd find some of the stuff you're doing useful.

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.

This is #29172, for other people's reference