[MacPorts] #32041: apple-gcc42: build fails when libunwind-headers is installed

[MacPorts]

#32041: apple-gcc42: build fails when libunwind-headers is installed
-------------------------------+--------------------------------------------
 Reporter:  dave@…             |       Owner:  jeremyhu@…           
     Type:  defect             |      Status:  new                  
 Priority:  Normal             |   Milestone:                       
Component:  ports              |     Version:  2.0.3                
 Keywords:  haspatch           |        Port:  apple-gcc42          
-------------------------------+--------------------------------------------
Changes (by ryandesign@…):

  * keywords:  => haspatch


Comment:

 Replying to [comment:10 ryandesign@…]:
 > I'll get you a log of the failure from Snow Leopard.

 Here it is: attachment:main.log.bz2


 Replying to [comment:11 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 [comment:6 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/32041#comment:12>
MacPorts <http://www.macports.org/>
Ports system for Mac OS