apple-gcc42: change behavior of the -isysroot option

[royliu@…]

When attempting to compile a port like virtualbox with the MacPorts apple-gcc42 compiler, strange errors like this occur:

/Developer/SDKs/MacOSX10.6.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory

After further investigation, this is because the -isysroot option is set. Recall that doing so will cause the search for the compiler's own headers to occur in directories like (in the case of Xcode's own llvm-gcc-4.2):

/Developer/SDKs/MacOSX10.6.sdk/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/include

Since we installed a MacPorts-based compiler, it will search in

/Developer/SDKs/MacOSX10.6.sdk/Developer/opt/local/lib/apple-gcc42/gcc/i686-apple-darwin11/4.2.1/include

Such a directory clearly doesn't exist, and this causes the apple-gcc42 compiler to not find headers like stdarg.h. The attached patch prevents prepending of the SDK root to the compiler's own search paths. I believe that this is a reasonable "fix" to the problem because:

1. MacPorts doesn't put a bunch of compiler-specific stuff into the SDK directories themselves.
2. The patch is essentially saying "Regardless of the SDK, I want to use a common set of compiler headers".

Again, this is not a bug, but more of a change tailor-made for the way that MacPorts distributes packages.

[royliu@…]

A patch that prevents prepending of the -isysroot option argument to the compiler's own search path.

[royliu@…]

I've also attached a cumulative patch for the port itself in patch-isysroot.diff.

[royliu@…]

The cumulative patch for the port itself.

[ryandesign (Ryan Carsten Schmidt)]

I imagine the portfile revision also needs to be increased.

[royliu@…]

By the way, if you deign to see the problem for yourself, try compiling test.cpp with build_test.sh without the patch. I've attached them.

[royliu@…]

A small test case which should fail without the patch.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, this seems like the right approach to me. The compiler's bits don't belong in the SDK anyways, so even if this "worked" before, we'd be getting the wrong headers.

I give this my maintainer blessing, but I'm confused why you modified other_langs.patch

[jeremyhu (Jeremy Huddleston Sequoia)]

Also, do we need to do this for the vanilla gcc ports as well?

[royliu@…]

A script to build the test case (revision 2).

[royliu@…]

Well, assuming the patch is reasonable, yes: All Apple-modified compiler ports require patching. If I'm not mistaken, that means:

• apple-gcc40
• apple-gcc42
• clang-2.9
• clang-3.0
• clang-3.1

Vanilla GCC doesn't seem to be affected, as search path modifications aren't present. Since this is such a far-reaching change, and since I'm not a compiler person, I am seeking your blessings as well as those of other compiler maintainers. :)

Replying to jeremyhu@…:

Also, do we need to do this for the vanilla gcc ports as well?

[royliu@…]

jeremyhu,

FYI, those patch changes help the patches apply without warnings. I've committed r87123 and am closing this for now. Please open a new bug if this change causes trouble.

-Roy

[jeremyhu (Jeremy Huddleston Sequoia)]

Nope, the change looks right to me. If anything crops up, we'll address it then, but I think this is "the right way" ... toolchain headers shouldn't be in the SDK anyways. Thanks for catching it.

[jeremyhu (Jeremy Huddleston Sequoia)]

Regression: #34233