Postby gawrilow » 11 Nov 2015, 13:41
polymake does not differ from any other perl library (or CPAN) module. It expects the loadable extension modules (those with .bundle suffix on MacOS X and .so everywhere else) in a subdirectory <PerlVersion>/<PerlArchitecture>/auto of one of locations listed in @INC. @INC is populated from several sources: first, locations configured together with perl itself (if your perl comes from a system package, the locations are defined by the packagers and usually should match your system well; if you are using a home-baked perl, you should know yourself what have you configured back then); second, locations contained in an environment variable PERL5LIB; third, locations dynamically added by perl scripts when they start. polymake uses the latter approach so that the user can install its components without obtaining root privileges; the location for polymake extension perl modules is specified during polymake configuration and it's populated by `make install'.
Now, looking at your @INC, one can deduce that your polymake has been configured with something like --prefix /home/mws/polymake-2.15-beta3, your perl has a slightly strange version string "perl5" (by default, an exact version string like "5.18.2" is used), and the perl architecture string is "x86_64-linux-thread-multi", which looks fine. In general, perl extension modules are not binary compatible across different versions, so that mixing extensions compiled for different perls may easily lead to any possible malfunction including immediate crashes, but I suppose you and your sysadmins know what they do.
Anyway, with this knowledge you can easily check whether your polymake installation conforms to the game rules or not. If /home/mws/polymake-2.15-beta3/lib/polymake/perlx does not contain anything, this would indicate that your `make all' or `make install' have failed underway and the installation is incomplete. Then you have to repeat the installation and watch out for any error messages.
If there are some files, in particular Ext.so and Ext.bs, but their location deviates from the naming scheme described above, this would indicate that you have built and installed polymake with a different perl version than you are trying to use now (maybe you have several perl installations in parallel, or you have upgraded your perl in the meanwhile). In this case you've got to rerun `configure --repeat x86_64', `make all', and 'make install' for polymake, using your new perl. (One can also specify the perl interpreter explicitly for all these commands by appending an option PERL=/path/to/my/weird/bin/perl.) You don't have to `make clean', however; if you have preserved the source and build trees from the last attempt, the new build will be very fast, because only a very small fraction of polymake binaries does depend on the perl version.
BTW, variables influencing perl installation behavior like INSTALL_BASE should never be set in environments of normal users. Such things are solely designed for packagers, that is, people building software which is going to be installed on other systems. Even if you share a non-standard perl module collection with other users across a local network, such setup can perfectly be maintained via properly configured site-perl directory and/or PERL5LIB environment variable.