ImageMagick's PC files contain -fopenmp which makes GCC 4.0 fail

[ballapete (Peter "Pete" Dyballa)]

When I try to compile GNU Emacs 24.0.92 with GCC 4.0 on Mac OS X 10.6.8 the configure script stops prematurely with:

checking for libXaw... configure: error: Lucid toolkit requires X11/Xaw include files

which config.log explains:

cc1: error: unrecognized command line option "-fopenmp"

This too modern switch is introduce from any of these PC files:

/opt/local/lib/pkgconfig/ImageMagick.pc:Cflags: -I${includedir} -fopenmp
/opt/local/lib/pkgconfig/MagickCore.pc:Cflags: -I${includedir} -fopenmp
/opt/local/lib/pkgconfig/MagickWand.pc:Cflags: -I${includedir} -fopenmp
/opt/local/lib/pkgconfig/Wand.pc:Cflags: -I${includedir} -fopenmp

One of them is asked by configure:

config.log:configure:10891: result: -fopenmp -I/opt/local/include/ImageMagick  

and than this compiler option is used. This is similar to tickets #15945 and #24944.

What about setting up a directory of backward compatible PC files without this -fopenmp switch?

My work-around is to copy a modified version of /opt/local/lib/pkgconfig/ImageMagick.pc into the root directory and modify PKG_CONFIG_PATH to contain .´´.

[ryandesign (Ryan Carsten Schmidt)]

That seems fraught... Wouldn't implementing #15945/#24944 (providing an openmp variant you could deselect) be the best solution?

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign@…:

That seems fraught... Wouldn't implementing #15945/#24944 (providing an openmp variant you could deselect) be the best solution?

I don't think so. This would switch off completely the use of modern features in ImageMagick (and possibly other packages) when compiling with modern GCC 4.4 or GCC 4.5. This time I just wanted to check whether it works to compile the sources of GNU Emacs 24.0.92 with such an old compiler as GCC 4.0 from Apple.

First try with GTK3 failed, a function _ _ sync_synchronize is used but not provided. Compiling with Xaw3d succeeds. So the OpenMP interface is not disturbing or prohibiting the successful build of software with ancient compilers, to me it therefore seems more appropriate to also provide PC files for such ancient software in some directory.

[ballapete (Peter "Pete" Dyballa)]

Replying to Peter_Dyballa@…:

First try with GTK3 failed, a function _ _ sync_synchronize is used but not provided.

This function is related to "memory fences" to allow out-of-order execution. And it is built-in to the compiler. This is likely something GCC 4.0 might not support. So trying to provide "backward compatibility" might not always succeed.

[kencu (Ken)]

works correctly with current compilers. Nobody is using gcc-4.0 any longer.