Opened 13 years ago

Closed 6 years ago

#30049 closed defect (worksforme)

GraphicsMagick fix for 10.7

Reported by: tk7r (Thomas Kotzian) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 1.9.99
Keywords: lion haspatch Cc: talezshin@…
Port: GraphicsMagick

Description

GraphicsMagick doesn't compile on 10.7 GM I have a quick fix for GraphicsMagick to make it work with 10.7 10.6 not tested

Attachments (1)

GraphicsMagick-10.7.patch (595 bytes) - added by tk7r (Thomas Kotzian) 13 years ago.
Portfile changes

Download all attachments as: .zip

Change History (13)

Changed 13 years ago by tk7r (Thomas Kotzian)

Attachment: GraphicsMagick-10.7.patch added

Portfile changes

comment:1 Changed 13 years ago by jmroot (Joshua Root)

Keywords: lion haspatch added
Owner: changed from macports-tickets@… to ryandesign@…

Please remember to cc the maintainer.

comment:2 Changed 13 years ago by tk7r (Thomas Kotzian)

Cc: thomas.kotzian@… added

Cc Me!

comment:3 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: talezshin@… added; thomas.kotzian@… removed

Has duplicate #30273.

comment:4 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: newclosed

Thank you; committing untested in r80964 since I don't have Lion yet.

comment:5 Changed 13 years ago by jmroot (Joshua Root)

Any reason we would want unfortified source on 10.6 and earlier?

comment:6 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: closedreopened

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.

comment:7 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: reopenedclosed

comment:8 in reply to:  6 Changed 13 years ago by jmroot (Joshua Root)

Replying to ryandesign@…:

I don't have a clue what fortification means.

It's extra bounds checking. See for example /usr/include/secure/_string.h.

comment:9 in reply to:  6 Changed 11 years ago by lpancescu (Laurențiu Păncescu)

Resolution: fixed
Status: closedreopened

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

comment:10 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Thank you for the detailed information and sorry for not addressing this issue sooner but it was a low priority for me because under recent versions of Xcode (4.2 and greater) MacPorts builds with clang anyway, and I don't support users overriding the compiler choice.

Before making any changes, I wanted to test various compilers to learn what happens.

On Mavericks, I am able to reproduce the issue using configure.compiler=macports-llvm-gcc-4.2. I am not able to reproduce the issue using configure.compiler=apple-gcc-4.2 or configure.compiler=macports-gcc-4.5 or configure.compiler=macports-gcc-4.8. So far, only llvm-gcc seems affected.

I still need to test other OS versions before I can decide what change to make.

comment:11 Changed 7 years ago by kencu (Ken)

Cleaning up old 10.7 tickets - this old ticket can be closed.

GraphicsMagick 1.3.26 compiles successfully on all systems. <http://packages.macports.org/GraphicsMagick/>, including 10.7.

Last edited 7 years ago by kencu (Ken) (previous) (diff)

comment:12 Changed 6 years ago by mf2k (Frank Schima)

Resolution: worksforme
Status: reopenedclosed
Note: See TracTickets for help on using tickets.