Thanks. It’s still in the early stages of downloading dependencies, but the Macports version seems more solid than homebrew…
What about the C api? I only saw a C++ header, and didn’t see any mention of it except on the homepage.
…the MacPorts gmic install failed after many hours. 
It failed at building luajit.
It was trying to install a huge dependency list and I wonder how much of those are actually used.
…I got passed the luajit stage by manually applying this patch:
https://trac.macports.org/attachment/ticket/59265/luajit.patch
Now it’s back on compiling llvm…
I would think that llvm and clang should be unnecessary since they are already installed with xcode, and they take ages to install. (Also, it had me install Java?)
I will write back in some hours I guess…
(PS. My opinion of MacPorts has become very low right now. Convoluted documentation, and it was painful to figure out the patch nonsense)
It failed again, talking about deactivating libunwind-headers for gcc…
(Again, gcc is already installed with xcode, so this is redundant)
Trying again…
Edit: gcc build failed, sigh, this is tiring.
I believe Xcode and MacPorts run separately, unless you can link libraries across opts, which I am not sure is possible. (I haven’t compiled anything on a Mac for almost 2 decades. 
)
This is from a quick internet search. If you want to figure out the dependencies and build configs etc., see here: macports/science/gmic at master · Schamschula/macports · GitHub. Looks like a Dr Schamschula is maintaining the MacPorts port of gmic, and I think the libgmic and libcgmic is built with gmic.
Sadly, there isn’t anything helpful there, and I have no insight how to get passed the libgcc9 failure.
Also, the actual dependency tree had 341 items! I counted them.
It looks like gmic is another one of those hopeless jenga tower projects. Is cimg the same way?
Maybe it’s time to wonder why most of the opensource projects maintainers I know have difficulties compiling / running their projects on Mac OS ? Ask GIMP developers, they encounter the same kind of issues.
Maybe it’s not a problem with the projects, but more with the OS itself ?
I was merely trying to test some trivial functions before sending it over to linux.
I work in simple C and directly with the GPU for all my image drawing/manipulation. I was interested to review if there are a couple algorithms in gmic/cimg that our studio can use. But when I see a list of 341 dependencies, most all of which are cringey, it is a bad omen, regardless of OS.
I’m really sorry for you it doesn’t work. But the truth is having to install 341 dependencies to compile G’MIC is a thing that happens only with MacOSX. You don’t have this problem on a more sane environment for developers.
Perhaps this is an important thing to put in the documentation.
“Gmic on the mac is currently a disaster. It is not fit for production use, and as of 2019, the install will not go smoothly.”
To me, I read the current website thinking that Mac was truly supported. - which it isn’t. A direct clear communication like that is important, otherwise people like me will waste days of time.
What about the C API that is mentioned on the front page? Does this exist in a production state on linux? If so, where is it?
…On linux, there are problems too.
The documentation is not correct. Is there a working set of installation steps written anywhere?
(PS There are indeed hundreds of dependencies for gmic on linux as well)
…and the compile errors for the tutorial with foo.cpp on linux are the same compile errors I get on the mac - what looks to me like dependency problems.
You are right, I’ll probably add this to the webpage:
You can compile the libc version of G’MIC with a minimal number of dependencies:
$ make clean
rm -rf CImg.h gmic_stdlib.h gmic use_libgmic use_libcgmic use_libcgmic_static gmic*.o libgmic* libcgmic* *~
$ make CURL_CFLAGS="" CURL_LIBS="" X11_CFLAGS="" X11_LIBS="" PNG_CFLAGS="" PNG_LIBS="" JPEG_CFLAGS="" JPEG_LIBS="" TIFF_CFLAGS="" TIFF_LIBS="" libc
make "CFLAGS+=-Dgmic_build -Dcimg_date=\\\"\\\" -Dcimg_time=\\\"\\\" -Dcimg_use_zlib -Dgmic_prerelease="\\\"191024\\\"" -std=c++11 -pedantic -Wall -Wextra -Wfatal-errors -Werror=unknown-pragmas -Werror=unused-label -Wshadow -Dcimg_use_vt100 -Dcimg_use_abort -Dgmic_is_parallel -Dcimg_use_fftw3 -fopenmp -Dcimg_use_openmp " "LIBS+=-lz -L/usr/lib -lm -lpthread -lfftw3 -lfftw3_threads -lgomp " _libc
make[1]: Entering directory '/home/dtschump/work/src/gmic/src'
> Retrieve G'MIC libcgmic files...
done!
> Retrieve G'MIC Standard Library...
done!
> Retrieve CImg Library...
done!
g++ -o libgmic.o -c gmic.cpp -fPIC -Dgmic_build -Dcimg_date=\"\" -Dcimg_time=\"\" -Dcimg_use_zlib -Dgmic_prerelease=\"191024\" -std=c++11 -pedantic -Wall -Wextra -Wfatal-errors -Werror=unknown-pragmas -Werror=unused-label -Wshadow -Dcimg_use_vt100 -Dcimg_use_abort -Dgmic_is_parallel -Dcimg_use_fftw3 -fopenmp -Dcimg_use_openmp
g++ -o libcgmic.o -c gmic_libc.cpp -fPIC -Dgmic_build -Dcimg_date=\"\" -Dcimg_time=\"\" -Dcimg_use_zlib -Dgmic_prerelease=\"191024\" -std=c++11 -pedantic -Wall -Wextra -Wfatal-errors -Werror=unknown-pragmas -Werror=unused-label -Wshadow -Dcimg_use_vt100 -Dcimg_use_abort -Dgmic_is_parallel -Dcimg_use_fftw3 -fopenmp -Dcimg_use_openmp
ar rcs libcgmic.a libcgmic.o
g++ -shared -Wl,-soname,libcgmic.so.2 -o libcgmic.so libcgmic.o libgmic.o -lz -L/usr/lib -lm -lpthread -lfftw3 -lfftw3_threads -lgomp
cc -std=c99 -o use_libcgmic use_libcgmic.c -L. -lcgmic
make[1]: Leaving directory '/home/dtschump/work/src/gmic/src'
$ ldd libcgmic.so
linux-vdso.so.1 (0x00007fff73b84000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4252577000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f425255b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f425253a000)
libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3 (0x00007f4252335000)
libfftw3_threads.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3_threads.so.3 (0x00007f425232c000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f42522f3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f425210f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4251fc1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4251fa7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4251dbc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4251db6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4252ed0000)
$ ldd libcgmic.so | wc -l
13
Job done.
2 Likes
I don’t use the libcgmic, so I can’t tell. @Tobias_Fleischer may help here, he is the author of the C bridge for the libgmic.
I am not aware which problems you might have. Still I am a Mac user since years and had compiled gmic and all other app of the package, not without problems, however any system makes problems!
Since you don’t have the need for the compiling and building environment why do write such a nonsense. Better write " I’d like to try gmic (cli) on Mac, how can I do that!
The answer for that question is:
Download gmic-cli-20191024.tgz
Unpack it, and add the folder gmic-cli to your path.
This should work !
Concerning your problems, I think your system it corrupt.
First step to overcome, create another user account (with admin rights) and use that instead.
Second step delete /opt/local, reinstall XQuartz and reinstall MacPorts.
It’s true, MacPorts installs a lot of incomprehensible ports, still even about 400 will not last to long since most of the ports are already in compiled form. Of course you should not try your special way from source, follow the instructions of the quick way! From source is starting from Adam & Eve to find the source of some personal specialities!
1 Like
KaRo,
I am not interested in the command line tool.
As I mentioned, I work in C and was intending to analyze a couple of the algorithms in gmic, and assess things as they are.
On the mac, the installation via both homebrew and macports failed. I don’t know what you mean that “they are already compiled and don’t take long” - for example, the heavy ones, llvm and clang, and all of the 341 are downloaded and compiled when calling the macports install gmic command, and this takes hours. - not to mention that I would not want these installed on our computers, and that they require individual patching on the latest Mac OS with new hardware. It has been clearly communicated that using the Mac is not supported, and I have moved on.
On linux, there are dependency and/or linking problems for both C++ and C. The information in the documentation about both installing and using the library even for linux is incorrect and I was not able to compile the example code.
Ok, I misunderstood you. Excuse my rude expression.
Still, I don’t understand why you try to compile gmic, which is, even under C or C++, only a different way to call gmic scripts or command pipes. I think you should better use the CImg header file. In the case of CImg there is the problem of dependencies completely in the hand of the programmer.
That you have even with linux problems is quite interesting, possibly some specialities on your computer? I ask me how @Carmelo_DrRaw is managing the mentioned disaster on Mac. Or, what is with my machine not having similar problems?
Concerning MacPorts “compiled binaries”: If you install MAcPort there are at least two possibilities, either from source or binary, I have called it the quick way. I have now followed several OS versions, hardware don’t matter so much, in fact I had sometimes to reinstall MacPort. Still it was for me a more versatile tool compared to homebrew.
Ok, you have moved on. In fact I have already made my way from Unix to Windows to linux and finally to MacOS. And there were enough reasons to “move on”! Good luck for new experiences!
Do you mean to say that none of gmic is written in C++, and that the C++ api is merely a wrapper that executes low-brow scripting languages?
My main intent here is merely to assess gmic/cimg in it’s natural habitat from a code-centered perspective (non-gui and non-command line)
So when I said I am moving on, it was merely in response to David’s communication that he does not support Mac. So I moved on to say ok, let’s install a fresh copy of linux and follow the website - and then it still failed with very similar dependency/linking compiler errors that I saw on the Mac.
If David or someone else can help describe the exact OS choice, and a specific list of working instructions for all the steps to install from a blank state, then I will follow them to the letter and continue the assessment.
It is very clear that the website documentation has been neglected as the very first line it tells you to run, is wrong.
I believe it also assumes that I will perform various actions that are not listed.
Unfortunately, I come from a mission critical work environment where the standard of quality is different (even something like libpng is banned for being unacceptable and we don’t use dependencies like this). Because of this, I have no clue how to go about doing these undocumented actions to fix the dependencies and linking errors.
If someone can spoon feed me the hacks I should do to install and compile on any version of OS, I will follow the instructions.
My main goal is foremost to survey the landscape of gmic/cimg and assess it objectively without rose colored glasses. We will then use the assessment to take (or not take) immediate actions this month.
No, gmic is written in C++, still it is mainly the script language and the mathematical script interpreter and some data input/output plus the hundreds of scripts. As far as I know the C and C++ API allows to load images (data) and process scripts or pipes and to return result data! Thats the reason that I recommend CImg which is in my opinion the underlayed processing part, besides a lot of logic to allow multi-processor computing in gmic resp. in the gmic plugin.
You mentioned a fresh installation of linux, by no means you have used a fresh MacOS in your trial. It is true that MacOS resists a bit in usage of open software and the package managers (MacPorts, homebrew) are only an aid to overcome problems. A fresh MacOS is not so resistant agains package managers.