CoCoA » CoCoA-5

Below is a copy of my notes about building libnormaliz from source -- I have version 3.9.4.
I use a "personal installation": so I specified the --prefix option when configuring.
It seems that --disable-shared is not important (at least on my old MacBook)

# Website  https://www.normaliz.uni-osnabrueck.de/download/

cd normaliz-3.9.4
export GMP_INSTALLDIR=/usr/local
./configure  --disable-shared  --disable-openmp  # --prefix=/home/jabbott/XYZ  (installation DIR)

make   #  took about 4 mins' CPU
--> result is in source/libnormaliz.la   or   source/.libs/libnormaliz.a
make check  # took about 1 minute

make install  # Went into /usr/local/include/,  /usr/local/lib/  and  /usr/local/bin (normaliz prog)

John Abbott wrote:

Below is a copy of my notes about building libnormaliz from source -- I have version 3.9.4.
I use a "personal installation": so I specified the --prefix option when configuring.
It seems that --disable-shared is not important (at least on my old MacBook)

[...]

Thank you very much. After disabling OpenMP on normaliz's side, the OpenMP errors no longer occur. However, the other QCodeEdit-related ones sadly persist.

Partial success: compilation succeeded, but attempting to run the resulting executable produced an error Cannot find shared object... presumably because libqcodeedit.so is not in an approved directory for shared libraries.

I must think about what to do. Also there could be a problem if we want to distribute the C5 executable, since we would have to include the shared library as well (together with instructions on what to do with it).

Or maybe I make the contents of QCodeEdit.pro.in depend on the platform...?

These differences between the linkers on Windows and Linux are really unfortunate sometimes...
In that case, I would leave it as-is for now. If there is a quick way to make the contents of QCodeEdit.pro.in depend on the current platform, that would obviously be even better.
For now, I have included another step in the instructions to change these two lines when being on a Windows machine.
And yes, the resulting library for QCodeEdit will need to be included in the binary distribution when linking it "un-static-ally".
I have looked a bit further into what I could do on the Windows side, but everything else didn't work sadly.
When I find something else, I will try it out, but for now I am out of ideas regarding this

John Abbott wrote:

Partial success: compilation succeeded, but attempting to run the resulting executable produced an error Cannot find shared object... presumably because libqcodeedit.so is not in an approved directory for shared libraries.

One way to solve this problem on unixoid systems is to adjust the RUNPATH in the header of the C5 binary so that the library can be found by the loader.

One simple way of achieving that here is to insert the line
QMAKE_RPATHDIR += QCodeEdit
into src/CoCoA-5/C5.pro.in. On several common platforms, qmake will then take appropriate precautions (likely set RUNPATH to $ORIGIN/QCodeEdit), so that the necessary shared object files are found in the subdirectory QCodeEdit.

This should be a good solution on platforms where qmake supports setting relative RUNPATHs, GNU/Linux and Darwin among them (see here). Lower level solutions are possible on other platforms, should anyone wish to run the GUI on them.

Thanks Ulrich! There's a lot I do not know about Qt (and many other things too). I hope to try out your suggestion soon:
with my "new" job in Kaiserslautern, I do not have so much time for CoCoA any longer :-(

It seems to have worked on my laptop (Ubuntu). I'll do a few more checks, but hope to include the change in the next interim release.

I can confirm that adding QMAKE_RPATHDIR += QCodeEdit does not break the build on Windows.
Thank you @Ulrich von der Ohe for finding out about that and mentioning it!