Postby gawrilow » 17 Jan 2017, 15:56
libpolymake-apps.so is a fake library used for linking standalone programs (or something embedded in third-party systems) together with the polymake callable library; it allows the standalone code to call public C++ functions from some application directly, that is, avoiding the overhead caused by perl wrappers hidden in CallPolymakeFunction and friends. All compiled applications are shared modules loaded on demand at some moment during polymake lifetime (more precisely, when the application has been requested for the first time). If the linker building the standalone program would see the application shared modules, it would record them as prerequisites of the entire executable, causing the dynamic loader to pick them way too early, and probably in wrong order. On MacOS it would even be completely impossible, because there they distinguish between dynamic libraries (preloaded when the executable is launched) and bundles loadable on demand like the polymake application modules. The fake library provides stub definitions of all public symbols defined in the application modules thus making the linker happy, so it records the SONAME of this fake library in the standalone executable; the whole mighty trick is that when the program is launched, that SONAME is resolved as a different library which does not contain any symbols at all; the proper implementations are loaded later, when the applications are requested, and resolved thanks to lazy binding.
Initially, the fake libraries would have different file names, making their roles more visible; on a gloomy day, this practice has been found offending some Debian policies, which endangered the inclusion of polymake in the Debian and Ubuntu repositories. We gave in and renamed the libraries, so that now they are only differing in the version suffix. If this trick is now frowned upon too, please give us an advice how to fix this without violating the Debian guidelines again.