apple-gcc42: build fails when libunwind-headers is installed

[dave@…]

This is on Lion.

This thread led me to try uninstalling libunwind-headers (I was getting the same compilation errors in my build log as shown there), after which apple-gcc42 built and installed flawlessly: ​http://gcc.gnu.org/ml/gcc-help/2008-04/msg00099.html

[royliu@…]

@dave,

Did the apple-gcc42 port get updated for you recently (after November 11)? The build failure may be related to a change I made.

-Roy

[dave@…]

I'm afraid I don't know; this was discovered as part of my port rebuild during a Lion upgrade

[royliu@…]

What was the approximate build failure time?

@jeremyhu, I say we close this and wait for more reports like this one to crop up. What do you think?

[dave@…]

Approximately the time at which I reported the bug

[ryandesign@…]

Replying to royliu@…:

@jeremyhu, I say we close this and wait for more reports like this one to crop up. What do you think?

I wouldn't close it until the problem is resolved. It's a real problem; I experienced it too on Snow Leopard with Xcode 3.2.6, and solved it by deactivating libunwind-headers, as indicated here. See also #32224 which may be the same problem or related. apple-gcc42 should either be fixed to install properly even when libunwind-headers is installed, or it should fail with a nice error message when libunwind-headers is installed telling the user to deactivate it first; see the ImageMagick Portfile for a nice reusable pre-configure block that can be used to do the latter.

[jeremyhu@…]

If this is "fixed" by removing libunwind-headers, then the bug is in libunwind-headers.

[ryandesign@…]

Are you sure? Couldn't it just as easily be that apple-gcc42 is placing -I${prefix}/include before -I. in its CPPFLAGS?

[jeremyhu@…]

No, I can't be sure, because nobody has provided me with a build log, and I'm not inclined to spend too much of my increasingly rare spare time working on a 5 year old compiler on a 4 year old OS. If someone attaches a build log, or the pre-processed source for the failure, I'll look at it, but based on what little information I have, I'm punting to libunwind-headers.

[ryandesign@…]

Then you're saying that even if you have libunwind-headers installed, apple-gcc42 builds correctly for you on Lion?

I'll get you a log of the failure from Snow Leopard.

[mfeiri@…]

I managed to reproduce the bug on a snow leopard system. What happens is that unwind.h from libunwind(-headers) shadows the internal unwind.h in gcc. I consider this a bug in gcc though. The gcc build scripts should properly arrange the order of the include dirs. Indeed this seems fixed in gcc43 and all newer versions of gcc. But I don't see myself spending time and effort backporting these fixes from gcc43 to apple-gcc42 (which would also trigger gplv3 concerns). My recommendation is to simply mark apple-gcc42 as "conflicts libunwind-headers" (or maybe even as "replaced_by clang").

[ryandesign@…]

proposed patch

[ryandesign@…]

Replying to ryandesign@…:

I'll get you a log of the failure from Snow Leopard.

Here it is: attachment:main.log.bz2​

Replying to mfeiri@…:

I managed to reproduce the bug on a snow leopard system. What happens is that unwind.h from libunwind(-headers) shadows the internal unwind.h in gcc. I consider this a bug in gcc though. The gcc build scripts should properly arrange the order of the include dirs. Indeed this seems fixed in gcc43 and all newer versions of gcc.

That's what I assumed the problem was.

But I don't see myself spending time and effort backporting these fixes from gcc43 to apple-gcc42 (which would also trigger gplv3 concerns). My recommendation is to simply mark apple-gcc42 as "conflicts libunwind-headers"

No; the conflicts keyword models activation-time conflicts (as in, two ports trying to install a file of the same name); it does not model nor prevent build-time conflicts. This must be handled as I already indicated above:

Replying to ryandesign@…:

or it should fail with a nice error message when libunwind-headers is installed telling the user to deactivate it first; see the ImageMagick Portfile for a nice reusable pre-configure block that can be used to do the latter.

I've now implemented this in attachment:apple-gcc42.diff​; Jeremy, please consider committing it.

(or maybe even as "replaced_by clang").

No; the entire reason the apple-gcc42 port exists is to provide a usable compiler for those ports that cannot be compiled with either clang or llvm-gcc-4.2. Since Xcode 4.2 no longer provides any version of gcc, we need a port containing a working version of Apple gcc for those ports to use. See ProblemHotlist#compiler and PortfileRecipes#compiler for how we're currently using this port, in many places.

[ryandesign@…]

Has duplicate #32224.

[jeremyhu@…]

r87623

[jeremyhu@…]

Thanks... the sooner we are off of gcc, the better...

[521E328E-2A13-4749-826A-E4EF4F22A0F1@…]

I just ran into this issue on Lion while updating my installed ports (port selfupdate && port sync) using:

% port upgrade -u outdated
--->  Computing dependencies for apple-gcc42
--->  Building apple-gcc42
Error: apple-gcc42 cannot be built while libunwind-headers is active.
Error: Please deactivate libunwind-headers and try again.
Error: You can reactivate libunwind-headers again later.
Error: Target org.macports.build returned: libunwind-headers is installed
Log for apple-gcc42 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_apple-gcc42/apple-gcc42/main.log
Error: Problem while installing apple-gcc42
To report a bug, see <http://guide.macports.org/#project.tickets>

Should the fix be available to me (after port sync)?

[ryandesign@…]

Replying to 521E328E-2A13-4749-826A-E4EF4F22A0F1@…:

The error message you are looking at is the fix: it tells you how to work around the issue:

Error: Please deactivate libunwind-headers and try again.

Cleaning apple-gcc42 before trying again would also be a good idea:

sudo port clean apple-gcc42

[dports@…]

Can't we make this work with libunwind-headers installed just by doing something like this? (see attached patch) We can avoid putting ${prefix} into the include path since we're not using any libraries from there -- mpfr and gmp are for Fortran only and we're not building that.

This works for me on Lion.

[jeremyhu@…]

Thanks. I need to revbump apple-gcc42 to fix the path to ld64 and also want to add in a symlink to as, so it will use our as provided by cctools. I'll do this at the same time.

[jeremyhu@…]

r91484