polymake tied to singular version?

[beew]

Hi, I have compiled polymake 4.9 against Singular 4.3.1 successfully. Tonight Singular was upgraded from 4.3.1 to 4.3.2 and ploymake started with the error

Code: Select all

ERROR: "/usr/local/share/polymake/perllib/Polymake/Core/CPlusPlus.pm", line 1785: Can't load shared module /usr/local/lib/polymake/lib/ideal.so: libSingular-4.3.1.so: cannot open shared object file: No such file or directory

Polymake was compiled with

Code: Select all

./configure --with-singular=/usr

Singular was installed from its deb repository https://www.singular.uni-kl.de/index.ph ... d/110.html and upgraded via apt.

The singular bin and libs are installed in these locations

Code: Select all

/usr /usr/bin /usr/bin/ESingular /usr/bin/Singular /usr/bin/TSingular /usr/bin/libpolys-config /usr/bin/libsingular-config /usr/lib /usr/lib/libSingular-4.3.2.so /usr/lib/libSingular.a /usr/lib/libSingular.la /usr/lib/libSingular.so

I thought polymake would link to libSingular.so rather than libSingular.so-4.X.X so one doesn't have to recompile polymake when there is a version change in SIngular.

OS is Ubuntu 22.04.

[gawrilow]

This is a general behavior of dynamic linking, nothing specific for polymake or Singular. When you link against a shared library, the linker records the SONAME property of that library in the produced binary as NEEDED property. Later, when it's executed, the dynamic loader looks for a library having this SONAME. You can check the SONAME and NEEDED properties using a command objdump -x; ldconfig -p will tell you the current mapping from SONAME strings to files installed on your system. So far the general theory.

In projects using semantic versioning schema, it's usual to trim SONAMEs after the major version, because changes in minor and patch versions are supposed to preserve backward compatibility. Please ask the Singular team whether they use this schema and if yes, why they are not setting appropriate SONAMEs in their build scripts. It could be a simple mistake or done on purpose, who knows...

For the time being, you can either rebuild polymake or try to trick out the dynamic loader. Rebuilding should be fast unless you already destroyed your polymake build tree. Tricking out would simply mean making a symlink libSingular-4.3.1.so -> libSingular-4.3.2.so. But if there are incompatible changes behind this upgrade, despite the innocent patch version bump, the stability of polymake will not be guaranteed as soon as you will use any function calling into Singular.

[beew]

Hi, thanks for the reply.

I checked again. Actually the list above got cut off. These are the Singular installed files

Code: Select all

/usr/bin /usr/bin/ESingular /usr/bin/Singular /usr/bin/TSingular /usr/bin/libpolys-config /usr/bin/libsingular-config /usr/lib /usr/lib/libSingular-4.3.2.so /usr/lib/libSingular.a /usr/lib/libSingular.la /usr/lib/libSingular.so

So libSingular.so was installed by Singular (it is a symlink to libSingular-4.x.x. I am just wondering why polymake specifically wants libSingular-4.x.x at run time instead of just linking to libSingular.so, and therefore needs rebuilding whenever Singular gets updated.

In any case I have rebuilt polymake, it doesn't take much time, just a bit of an annoyance.

[gawrilow]

... I am just wondering why polymake specifically wants libSingular-4.x.x at run time instead of just linking to libSingular.so, and therefore needs rebuilding whenever Singular gets updated

I tried to explain this in my previous response. polymake does not have any specific desires, it's the normal behavior of dynamic linker. libSingular-4.3.2.so must contain the SONAME header with exact this contents. You can check it using the objdump utility.