Install OMP shared library AND symbolic link

[godotalgorithm]

Sigh, yet another correction to fix the incorrect fix in #46. Previously, I had accidentally installed the symbolic link to the shared library, but not the shared library itself. I replaced that with installing the shared library, but not its symbolic link, because I thought that the executable contained a path to the underlying shared library. Apparently, I'm wrong and both the shared library and its symbolic link need to be installed.

Status

• [x] Ready for merge

[codecov-commenter]

Codecov Report

Merging #72 (9901ac6) into main (f10d4d9) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #72   +/-   ##
=======================================
  Coverage   68.23%   68.23%           
=======================================
  Files         330      330           
  Lines       71706    71706           
=======================================
  Hits        48932    48932           
  Misses      22774    22774           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f10d4d9...9901ac6. Read the comment docs.

[godotalgorithm]

On closer examination, I have misunderstood the problem. It is correct that the executable is pointing to the underlying shared library and not any symbolic links to it. However, the Linux executable is now pointing to two separate OpenMP libraries, libomp.so.5 and libiomp5.so. In some instances, libiomp5.so is a symbolic link to libomp.so.5, but in other instances it is a shared library unto itself. This appears to be confusing the linking process on Linux somehow, and it is very likely to be related to my recent reactivation of the THREADS keyword. This PR is thus irrelevant and misguided.