[MacPorts] #30049: GraphicsMagick fix for 10.7

[MacPorts]

#30049: GraphicsMagick fix for 10.7
-------------------------------+---------------------------
  Reporter:  thomas.kotzian@…  |      Owner:  ryandesign@…
      Type:  defect            |     Status:  reopened
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:  1.9.99
Resolution:                    |   Keywords:  lion haspatch
      Port:  GraphicsMagick    |
-------------------------------+---------------------------
Changes (by lpancescu@…):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Replying to [comment:6 ryandesign@…]:
 > I don't have a clue what fortification means. All I know is the build
 seemed to succeed on Snow Leopard with the change so I committed it.
 >
 > jeremyhu already suggested on the mailing list that we use clang instead
 of llvm-gcc-4.2 so I'll do that instead.

 The problem with using clang is that clang doesn't support
 [http://en.wikipedia.org/wiki/OpenMP OpenMP], and AFAIK there are no plans
 for implementing that. For GraphicsMagick, that means that only one
 processor core is used, making it almost two times slower on my dual-core
 Mac Mini (more for people with quad-core or eight-core).

 Instead of overriding the compiler when the user specified gcc, we can use
 the following:
 {{{
 if {${configure.compiler} == "llvm-gcc-4.2"} {
     configure.cflags-append "-D_FORTIFY_SOURCE=0"
 }
 }}}

 I already tested here (10.8 Mountain Lion), it compiles with llvm-gcc-4.2
 and works correctly - I got a run time of 0m:50s instead of 1m:44s when I
 processed some scans for taxes.  The best way would be to append those
 CFLAGS to any gcc variant, not just Apple's llvm-gcc-4.2 (gcc-4.7
 generates faster code than both llvm-gcc-4.2.1 and current clang).

 A few words about "source fortifying": some functions from the standard C
 library are very fast, but can be used in an unsafe manner, like memcpy or
 strcpy.  If you copy more data than there's place in the destination
 buffer, you'll get a buffer overflow if the destination buffer is on the
 stack, or heap overflow if dynamically allocated.  Both are bad, and can
 result in execution of arbitrary code.  In some cases, the size of the
 destination buffer is known at compile time, and the compiler is able to
 insert a check in the generated code, causing a segmentation fault (rather
 than arbitrary code execution) at run time, if more data is being copied
 than the buffer size would allow.  This is controlled by the
 _FORTIFY_SOURCE macro, with possible values of 0, 1 and 2; 0 means
 disabled, and 2 is the strongest protection (this is what many "hardened"
 Linux distributions use).  However, this check needs support in the C
 runtime library, otherwise you'll get that link error about
 !__builtin_object_size missing.  The support was there until Snow Leopard,
 and disappeared since Lion.  In general, on Lion+ one needs to disable
 source fortification for compiling C code with any variant of gcc.

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