As explained in this other post, I am setting up an infrastructure on GitHub/TravisCI to compile and package some commonly used GIMP plug-ins.
The first thing I have worked on is a G’MIC GIMP plug-in for OSX, and after two weeks of struggling with the library dependencies I have finally succeeded to package a GMIC-Qt plug-in that seems to work properly with the official GIMP DMG.
As stated in the other post, the installation of the plug-in is rather simple. All one needs to do is download this archive and extract the contents in one of the following folders:
$HOME/Library/Application Support/GIMP/2.10/plug-ins if GIMP is installed in its default location (/Applications/GIMP-2.10.app)
in @GIMP_APP@/Contents/Resources/lib/gimp/2.0/plug-ins in the other cases, where @GIMP_APP@ must be replaced by the path to your GIMP app bundle.
It would be great if OSX users could try the plug-in and let me know wether it works or not for them…
@KaRo if I am not wrong you have been maintaining the OSX version of the G’MIC plugin in the past. Would you be interested to collaborate on this? Everything is available on GitHub: GitHub - aferrero2707/gimp-plugins-collection
EDIT: @David_Tschumperle I forgot to mention that I had to apply this patch to the plug-in sources in order to correctly find the additional libraries and frameworks, needed by G’MIC and not included in the GIMP bundle. The patch allows to properly detect the absolute path of the gmic_gimp_qt executable and set the QT_PLUGIN_PATH environment variable accordingly.
That’s interesting thank you. Would it be possible you submit a pull request to the gmic-qt project on Github ? I 'm sure Sébastien (the main developer of G’MIC-Qt) would appreciate it.
Also thanks for the amazing work. I cannot test but this looks really promising
Surely I can do it. However, the folder which gets added to the QT_PLUGIN_PATH is currently very much specific to the way I am packaging the OSX plug-in. It will be up to you and Sébastien to decide if it can be taken as “the official way to go”…
Anyway, I will prepare a pull request a bit later today.
Hi, just tried your package with original. Very good, congratulations!
I never reached (and tried to reach) that point.
Still I will look into your scripts and possibly try to build some sort of bundle of gmic CLI similar to your approach for the plugin version. There are perhaps some users of it on Mac like me.
Still actually I am using MacPorts for Gimp and gmic. There is for bundles always the problem of updates…
I have built the plugin with the MacPort Libraries and had than the problem with updates in MacPorts, newer libraries compared to libraries in the Gimp bundle! I could not read from your script how you link the libraries. If you use the brew packages you might run into the same problems, Gimp builds are typically much older. I am not so keen to redirect the link library path to the Gimp bundle at build time. Maybe you have found a way?
For the CLI I think I could try to copy the necessary libraries into a folder, but what about dependencies in those libraries? Do you check them all recursively?
Yes, I found it, and that’s what took most of the time…
I actually found two very useful programs:
optool which allows to manipulate the DYLIB LOAD commands in the MacOS libraries
macdylibbundler which allows to recursively collect the run-time dependencies and patch the library paths
I have modified the first tool to also change the version information of loaded libraries. This way, I can compile the plug-in against the libraries provided by homebrew, but then let the executable link at run-time to the libraries contained in the GIMP bundle. The point is that the plug-in only uses symbols from BABL/GEGL/GIMP, so binary API compatibility is only required for those libraries. In other words, linking to a newer version of gdk_pixbuf is not a problem because the plug-in does not use gdk_pixbuf functions directly. When running, the plug-in will link to the BABL/GEGL/GIMP libraries in the GIMP bundle, and will happily use the older version of gdk_pixbuf available there.
I hope this rant is sufficiently clear… at some point I want to write a blog post to better explain my findings, which might be useful for other plug-ins as well (my next item on the list is the amazing “liquid rescale” plug-in).
The places where I use those “magic” tools are here and here. The rest is a lot of quite complicated and boring gymnastics with otool -L and install_name_tool…
I have just finished improving my Travis CI scripts. Now the building/packaging procedure is fully automated: a daily cron job compares the GMIC and GMIC-Qt commit hash of the latest build with respect to the HEAD version of the corresponding repositories, and triggers a re-build whenever some newer commit is present in at least one of the two repositories.
Really good, thank you too, large improvement for Mac user!
Still it might be good to consider as third repo CImg,for changes, in fact it is quite central for gmic.
… and tested the 141118 version against Gimp 2.10.8
