Singular

No, it is not a bug.
Probably polymake.so is not built to support polymake:
either polymake (and polymake-config) was not present at build time
or Singular was not able to extract the version of polymake out of it
(see config.log for details).
If you comment it out, the routines relying on polymake will not work,
otherwise no problems.

I've encountered a problem loading brillnoether.lib on Singular 4.1.0p3.

[code]
> LIB("brillnoether.lib");
// ** loaded /home/baccala/src/singular-4.1.0/Singular/LIB/brillnoether.lib (4.0.1.0,Oct_2014)
// ** loaded /home/baccala/src/singular-4.1.0/Singular/LIB/divisors.lib (4.0.0.0,Jun_2013)
// ** loaded /home/baccala/src/singular-4.1.0/Singular/dyn_modules/customstd/.libs/customstd.so
// ** loaded /home/baccala/src/singular-4.1.0/Singular/LIB/polymake.lib (4.0.0.0,Jun_2013)
// ** customstd.so already loaded as package
// ** loaded /home/baccala/src/singular-4.1.0/Singular/dyn_modules/gfanlib/.libs/gfanlib.so
? mod_init not found:: /home/baccala/src/singular-4.1.0/Singular/dyn_modules/polymake/.libs/polymake.so: undefined symbol: mod_init
This is probably not a dynamic module for Singular!

// ** `mod_init` in use, can not be killed
? error occurred in or before polymake.lib::mod_init line 142: ` LIB "polymake.so";`
? leaving polymake.lib::mod_init
[/code]

I don't have this problem with Singular 4.1.1, but 4.1.0p3 is still a problem because that's what Sage currently uses.

I fixed this by commenting out one line from polymake.lib's mod_init() function:

[code]
static proc mod_init()
{
intvec save=option(get);
option(noredefine);
LIB "customstd.so";
LIB "gfanlib.so";
// LIB "polymake.so";
option(set,save);
}
[/code]

Is this a bug? Should polymake.lib be loading polymake.so, or is this a recursive loop?

Singular 4.1.1 seems to work fine with this line still there, so I'm not sure if this is the reason for my problem with 4.1.0p3. I don't know Singular well enough to know.