Packages requiring additional shared libraries look for them at a wrong location: they use the hard-coded build directory location

[yurivict]

At least these 2 packages have this problem: semigroups, normalizinterface.

The installed gap with packages looks for the shared library in the build directory instead of looking in the install directory.
For example, the semigroups package looks for the library /usr/ports/math/gap/work/gap-4.15.0-beta1/pkg/semigroups/bin/lib/libsemigroups.so.3 (where it was built), and not in /usr/local/share/gap/pkg/semigroups/bin/lib/libsemigroups.so.2 where it is installed.

The lookup should be in a location relative to the current gap executable, not in a memorized build location.

This problem prevents packaging: it leaves these packages broken.

Version: 4.15.0-beta1
OS: FreeBSD 14.3

[wilfwilson]

@james-d-mitchell FYI

[fingolfin]

You talk about this in the plural, but list only one example (semigroups) where we already established a different cause (see #6100 and libsemigroups/libsemigroups#796).

Are there any other packages that exhibit such a problem? Which ones?

[yurivict]

The OP's first line lists them: semigroups, normalizinterface.

#6100 has nothing to do with this issue by the way.

[yurivict]

IMO this issue is a must-fix for the upcoming release.
Otherwise there's no way to package at least 2 GAP packages.
I tried this on FreeBSD and these 2 packages are installed broken.

[fingolfin]

The default for GAP users is to build those by running prerequisites.sh scripts, which do some linker hackery to make sure the uninstalled versions of those dependencies can be used by the kernel extensions.

But if you want to install these packages system wide, then that is not what you want to do. Instead, you should use suitable configure args (e.g. --with-normaliz=PATH) to point them at an installed version of their dependencies. Either one in an existing package for normaliz / libsemigroups 2 ; or you install the vendor'ed versions of those dependencies somewhere (e.g. into the same location as those GAP packages)

---

If this doesn't help, it might be some FreeBSD specific issue.
It is difficult to tell without knowing what exactly you are doing, i.e., what the precise build steps are you are taking to build those packages, what the outputs are etc. -- perhaps you can post or attach logs here?

---

Alas, I have no knowledge about FreeBSD and not even easy & convenient access to a FreeBSD system. So the only way to get this resolved for FreeBSD is if someone who actually knows about FreeBSD to help out.

In the end, while I'd love to support FreeBSD, it is not a first tier target for us (unlike Linux, Windows, macOS), so I am afraid this is not a release blocker for 4.15.0. But there is still some time to get it resolved before that is released, and if not, there is always 4.15.1.