Compiling G'MIC on various platforms


(Tobias Fleischer) #1

As some of you might know, I am working on various G’MIC related projects, and for that I compile and work with the sources and libraries on various platforms like Windows, MacOS and Linux all the time.
Here are some of my personal experiences and insights with different compilers and operating systems when compiling G’MIC, maybe they are useful to some of you. Feel free to add/correct me if you know more about specific topics :slight_smile:

On Microsoft Windows, there are basically two approaches for compiling the G’MIC sources: either using the GNU C/C++ compiler collection (GCC) or using Microsoft Visual Studio.

The GCC approach is the recommended one (and also used for building the official G’MIC binaries).
I recommend installing MSYS2 (a Unix tool/emulation layer, available here and using the MinGW compiler toolchain that comes with it. MSYS2 includes a nifty packet manager called “Pacman” that makes installing required third-party libraries and compilers a breeze.
I wrote a detailed description on how to set the whole toolchain up on Windows using this and then compile G’MIC with it. This information will be published soon on my website.

I tested it with the latest GCC version (GCC 7.1.0 from May 2017) and no changes to the Makefile were necessary. I linked against the libjpeg, libpng, libtiff, fftw3 OpenMP, OpenCV and curl libraries and it gets compiled within some minutes with full optimisations ("-O3" option).
One thing to note is that because in the Makefile display of all compiler warnings is enabled ("-Wall" option), you might get a lot of (harmless) warnings in the G’MIC sources. Particularly the new “fallthrough warning” in GCC when you use the “case” option in a “switch” statement without a “break” for each option will appear quite often, but it can be disabled with the “-Wimplicit-fallthrough=0” switch.

Now there is also the option of compiling with Microsoft’s own Visual Studio, although that still has some severe disadvantages:
G’MIC extensively uses a compiler feature called OpenMP ( that automatically runs certain code parts in parallel, making them faster. The G’MIC sources use OpenMP 3.x or above based commands, available in the GCC compiler suite for a long time. Microsoft Visual Studio however only supports OpenMP 2.0 and only in their commercial suite of compilers, not in the freely available ones. You therefore have to disable OpenMP support for Visual Studio builds, making certain complex G’MIC algorithms much slower.
The other big disadvantage is that the Microsoft compiler has problems with optimisation turned on when the code is extensively using nested templates and macros. This has been acknowledged by Microsoft since several years, but no remedy is in sight. In our case that means that the G’MIC sources compile within some seconds when optimisations are switched off, but when they are on, it might take literally hours to build (I recently stopped at about 5 hours compilation time!).

So, yes, you can build G’MIC in Visual Studio, but only without parallel processing and optimisations. I was surprised however that even the reduced build ran for the most basic operations at a similar speed as the GCC compiled one. Of course, the more complex and computation-intensive a G’MIC command/algorithm is, the more recognizable the difference will be.

It might still be a worthwhile road to follow if you have a Visual Studio project that you directly want to integrate with G’MIC. If you don’t want to use this compromise, but are bound to Visual Studio still, there is another option: some years ago I introduced an ANSI-C interface to G’MIC that makes its functionality accessible across compilers. So we can now build a fully optimized G’MIC library in GCC for example and then use the libcgmic/libcgmicstatic import library in Visual Studio to reference and use this. Best of both worlds for some :slight_smile:
I created Visual Studio solutions/projects to build the various G’MIC components from there, these will also be published soon, probably in the G’MIC community repository where also my C interface resides.

Another problem some developers on Windows with Visual Studio might face is that you need exactly the right third-party libraries for that compiler and its project settings, which might be quite difficult to set up. Therefore I have also created Visual Studio project files for the sources for various open-source libraries like libjpeg, libpng, libtiff, libcurl, fftw3, zlib, pthreads, etc. If there is interest in these, I will also make them available to the public.

Moving on to the Apple desktop operating system.
Since this has an underlying Unix-derived base, some things are a bit easier to set up.
MacOS is however lacking a standard packet manager to install all the needed dependency libraries. You can of course compile and set them up manually, but I recommend using one of the existing free third-party packet managers. The most common ones seem to be “Fink” (, “MacPorts” ( and “Homebrew” (

I think KaRo’s G’MIC Mac builds ( are linked against MacPorts, but I wanted to try something new and used the newest of the bunch, “Homebrew”. It is really easy to install and get the required bundles, so the libjpeg, libpng, opencv, etc. stuff were available in no time.
The Makefile could also be used without modifications once all the required libraries were present. Interestingly, on my Mac OS X 10.11 system, I ran into a similar problem as on Windows with Visual Studio: when optimisations were on full ("-O3"), it took ages to compile (I stopped after 3 hours). Setting it one level lower to “-O2” brought it down to minutes and disabling optimisations alltogether made it compile really fast. Not sure if anyone has any recommendations/insights how this could be improved.

Another problem I ran into on MacOS is however that by default in the Makefile, MacOS builds are compiled against the X11 (standard X.Org X Window System) display library for G’MIC. However since MacOS 10.8, Apple decided to deprecate this and now longer ships supporting libraries and applications for it. The recommended solution for this is to install the open-source application XQuartz ( which brings back X11 support for MacOS. Once installed, G’MIC then also runs fine with its X11 display.
Does anyone know if there is an alternative to X11 for G’MIC display on MacOS? Either possible at the moment or planned in the future? Any input would be appreciated.

Now that is of course relatively easy - given that you have all the required libraries and headers available to link/compile against. On my Ubuntu 15.10 system it was relatively easy to set up and compile with full features. For “libtiff” and “curl” I had to make sure I had the specific versions installed that the compiler requires and modify some symbolic links on my system for the include paths.

Well, so that is my experiences from the last week trying to compile the most recent G’MIC sources (2.0.3pre) on various operating systems with different compilers. As I said, I will make all the info and project files I added myself available in the next weeks, maybe it helps others as well.

(Karsten R) #2


Just my one and a half cent concerning g’mic on MacOS:

There is now a port of g’mic on MacPorts. Hence I will not build anymore the g’mic command line interface. Still there is neither gmic_gimp plugin port or port option, nor a port for gmic_qt with options HOST=none or HOST=gimp or any other possibility. Still the qt plugin works well with gimp port under MacPorts.

For the plugin the main problem are the users without development environment. As far as I see there are only the Partha Gimp build ( quite recent and the slightly older lisanet Gimp build (, which I use to build the plugin (release and git) against. Disadvantage of Partha build: no X11 interface for the plugin interactive functions and, compared to the revision frequency of gmic, a slow update. Disadvantage of the lisanet build: no qt interface and recent gmic_gimp builds only for Sierra and newer and slow Gimp update. It is a real pity that the Gimp maintainer ( don’t add some necessary libraries into the Mac Gimp bundle to allow the attachment of gmic plugin. Since some time I prepare a plugin build for that org Gimp build with less functionality following the bundled libraries therein …

Concerning the package manager on Mac: The main problem are IMHO the diverging versions of the packages of the three package managers mentioned. In fact I started with Fink, went over to MacPorts stepped over to Homebrew and went back to MacPorts since Homebrew didn’t like the build of apps (like Gimp) and lisanet Gimp build bases on MacPorts. Perhaps there will be a MacOS future of the plugin, probably without me, similar to Windows with by-packed libraries?

Compile time on Mac is a mystery for me too. Small changes in CImg, the underlying gmic software, change it drastically. My gmic build actually needs about an hour (-O3), the MacPorts build about 2h, the plugin builds (lisanet and about 1 and a half hour together (all -O3).

Karsten aka karo

(Tobias Fleischer) #3

Thanks for your input, Karsten!
I heard about the various complications and incompatibilities concerning the libraries for the GIMP plugin, but to be honest, I never looked into them (and was glad I did not have to :slight_smile: ).
All my experiences in compiiling the code relate to compiling the shared libs and the CLI interface, I haven’t tackled or looked at building the GIMP plugin on MacOS. I really hope it will get better in future!

(David Tschumperlé) #4