Thank you for the suggestion. I am not a large GitHub user and to talk about my scripts is actually an exaggeration. I did only, mostly blindly taken from your scripts, inside the gmic source
The list of dependencies ? Do you mean the libraries listed in my gmic built:
otool -L gmic
/usr/local/bin/gmic:
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
/opt/local/lib/libfftw3.3.dylib (compatibility version 9.0.0, current version 9.8.0)
/opt/local/lib/libfftw3_threads.3.dylib (compatibility version 9.0.0, current version 9.8.0)
/opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0)
/opt/local/lib/libpng16.16.dylib (compatibility version 52.0.0, current version 52.0.0)
/opt/local/lib/libjpeg.9.dylib (compatibility version 13.0.0, current version 13.0.0)
/opt/local/lib/libtiff.5.dylib (compatibility version 9.0.0, current version 9.0.0)
/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
/opt/local/lib/libIlmImf-2_2.23.dylib (compatibility version 24.0.0, current version 24.0.0)
/opt/local/lib/libHalf.23.dylib (compatibility version 24.0.0, current version 24.0.0)
/opt/local/lib/libopencv_dnn.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_ml.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_objdetect.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_shape.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_stitching.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_superres.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_videostab.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_calib3d.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_features2d.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_highgui.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_videoio.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_imgcodecs.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_video.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_photo.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_imgproc.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_flann.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/opt/local/lib/libopencv_core.3.4.dylib (compatibility version 3.4.0, current version 3.4.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
or do you mean the result of your dylibbundler program?
Thank you, ls -la libs is the result of the dylibbundler program which should have resolved all dependencies. Seemingly there is some circling during the resolving of dependencies in that program!
@HIRAM I have under Mojave no problem. What version of MacOS are you using and is there another package manager involved?
As you can see pretty much everything is compiled to run on Mojave, I’m on Sierra. This often happens when bundling with managed packages from MacPorts or Homebrew. Yes dependency resolution is a complex matrix problem so recursion is definitely involved there. As far as the avcodec goes, you might want to try downgrading back to FFmpeg v3.4.
for f in *; do echo file=$f; sudo otool -l $f | grep -A4 'LC_BUILD_VERSION\|LC_VERSION_MIN_MACOSX'; done
That is a bit above my level. Still I must confess, I have reinstalled MacPorts after upgrading to Mojave, hence… Downgrading in MacPorts is afaik not possible. To build all new similar to partha.com 's approach for Gimp & plugins is far beyond my possibilities. I don’t know if it is possible to build MacPorts packages with minos=10.8
Possibly the problem could be resolved or reduced using the program optool mentioned and used by @Carmelo_DrRaw to correct or change versions of libraries? Actually I could not try optool, there are missing header files!
Unfortunately this can only be used for the case of the GIMP plug-in, which uses run-time libraries that are different from compile-time ones.
In the CLI version we need to do things properly, i.e. recursively pick and fix all dependent libraries, which is what I am trying to do right now (see here). However, there seems to be something strange with the OpenCV libraries provided by Homebrew, that I am still investigating. Currently macdylibbundler stops before copying all dependencies.
Hmm I don’t see that. Some time ago I built gmic cli against the libraries bundeled in the Gimp app. Perhaps one can consider that as an independent plugin. Of course several things didn’t work like opencv or net access, at least everything not built in Gimp.
The behavior of macdylibbundler is difficult, with MacPorts libraries it finished properly…
One big benefit of using github+Travis is the availability of the osx_image: xcode6.4 based on OS X 10.10. Anything built in that environment with that sdk should work for 10.10+.
dyld: Library not loaded: /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
Referenced from: /Users/aferrero/Downloads/gmic-cli 8/libs/libavcodec.57.107.100.dylib
Reason: image not found
I do not have the CoreImage framework on my system…
@KaRo@HIRAM
I am happy to say that I did quite some progress on this topic, and I have now a working version of gmic-cli for MacOs 10.9 and later. However, it comes without opencv support for the moment.
The main problem I had to face is the availability of binary packages that are compatible with MacOS versions earlier than the one being used for the builds. I have discovered that most of the bottles that homebrew provides for High Sierra (the system used for my Travis CI jobs) are only compatible with MacOS 10.13 and later, which is too restrictive.
After some thinking and researching I ended up making my own bottles, built with the following additional compiler flags:
Those bottles are also created under TravisCI, using the same OSX image as the one used to compile GMIC, to guarantee as much as possible the consistency of the builds.
The repository with the custom homebrew formulas is here: GitHub - aferrero2707/homebrew-bottles: Custom bottles for building universal bundles on Travis CI. It should be expanded to include other common packages that do not provide enough backward compatibility… requests are welcome.
What do you think? Could you test the gmic-cli package and let me know if it works for you as well?
Congratulations ! I tried gmic on my actual Mojave 10.14.1 as well as on my Yosemite 10.10.5, both with MacPorts, no HomeBrew, no problem. Besides that I tried it on an empty Mac Mojave, no packagemanager however, no problem however. For display I had to install XQuartz only.
I think the lack of opencv is acceptable, at least for me. I used the camera mostly for testing purposes. There is still the stable gmic package in MacPorts with opencv. Perhaps something similar exist in HomeBrew.
That is a large progress Andrea. If you plan to prepare regularly builds, I think we should convince David to replace my dead link in the downloads by yours. Under these circumstances I think I will stop to build gmic from git even for my private use, your built is better! What about the plugin? Will it be actualized too?
Yes, this is exactly my plan. It will work in the following way: 1) the builds will save the git HEAD hash of the gmic repository together with the generated tar archive 2) the next build will first clone the gmic repository and compare the current hash with the one previously saved 3) if they differ, the job will proceed building a new tar archive, otherwise it will stop.
I will set up a daily cron schedule for the jobs, so that new versions will be available at most 24h after the corresponding commit.
I have just triggered a new build, and then I will set-up a similar mechanism for automated updates…
Just for the built, it might be good to let the pre_release tag with the date for these git builds gmic and gmic-qt set to have some info about the source and time used either in version or in the window header.
