Purpose of libpolymake-apps

Discussions on installation issues go here.

Moderator: Moderators

jamesjer
Posts: 26
Joined: 01 Mar 2012, 16:51
Contact:

Purpose of libpolymake-apps

Postby jamesjer » 17 Jan 2017, 05:10

A question has arisen within the Fedora project. I have been asked to explain why libpolymake-apps.so is not only not a symbolic link to libpolymake-apps.so.3.0, but the two files appear to have been compiled from different sources. The reason for the query is the ldconfig work going on here: https://bugzilla.redhat.com/show_bug.cgi?id=1380878. Polymake is identified as one of the "weird" packages in comment 2. I do not understand the purpose of these libraries. Can somebody educate me, so we can determine how best to handle the situation in the Fedora project? If documentation exists somewhere, a pointer to the documentation is sufficient. Thank you.

User avatar
gawrilow
Main Author
Posts: 260
Joined: 25 Dec 2010, 17:40

Re: Purpose of libpolymake-apps

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.

jamesjer
Posts: 26
Joined: 01 Mar 2012, 16:51
Contact:

Re: Purpose of libpolymake-apps

Postby jamesjer » 19 Jan 2017, 17:59

Thank you for the explanation. That helped a lot. Polymake does not currently violate any Fedora packaging guidelines. The question arises in the context of some work on attempting to optimize ldconfig invocations during package installation.

Would it work as well to mark all application symbols as weak symbols when compiling a standalone program? That is, instead of generating a C file containing stub definitions for all application symbols, how about generating a header file that contains definitions like this for all application symbols?

#pragma weak foo
int foo(...);

Of course, not all compilers support #pragma weak, so this is not very desirable from your point of view. Hmmm. I will talk with the Fedora people working on the ldconfig project and see what we can figure out. Thank you for the time you took to respond.


Return to “Installing polymake”

Who is online

Users browsing this forum: No registered users and 1 guest

cron