forum.polymake.org

I've found the bug. Please find attached a small patch fixing it. I suppose you are working with release 2.12. Apply the patch using command 'patch -p1' from the unpacked source directory of polymake, then run 'make install'.

Sorry for the late reply. The patch works fine! Thanks a lot!

...
Does this mean that something with my polymake installation is wrong?

No, but you are the first pioneer trying to call a function residing in an application shared module directly from an external program. The usual compiler/linker flags are not sufficient in this case. You should add the module graph.so (or .dylib if you are building on a Mac) to your linker command. It is located together with other applications' shared modules in the subdirectory polymake/lib (relative to the location of your libpolymake.so).

I built this on a mac by now.
Just in case anyone else wants to do the same: It's not a graph.dylib but a graph.bundle (at least on my machine). I'm not too sure how to handle these bundles from a c++ program as one can't link against them like an ordinary library (as far as I know one has to load them at runtime). I was able to work around this by adding " -undefined dynamic_lookup" to the linker flags and not do anything with the graph.bundle file. Note that the "-Wl,--warn-unresolved-symbols" flag is not recognized by ld on a mac. Might not have been the most elegant way, but at least everything compiles and runs as it should.
Sören

Hi,
can I assume that the facets given by (for sake of simplicity let us consider only a 3-dimensional polytope)
Are in the same order as ?

Yes and no.

The order of nodes of dim=0 or co-dim=1 is indeed identical to that of the vertices resp. facets of the polyhedron.

But you should never access the DIMS property directly, some face lattice objects are built in ascending dimension order, others in descending order. Always use the method nodes_of_dim(). For facets, you can call it with the argument -1, that is, co-dimension 1.

Thanks. Yes, I'm always using nodes_of_dim, just quickly took the example from your tutorials. Nice to know nonetheless.

...
Does this mean that something with my polymake installation is wrong?

No, but you are the first pioneer trying to call a function residing in an application shared module directly from an external program. The usual compiler/linker flags are not sufficient in this case. You should add the module graph.so (or .dylib if you are building on a Mac) to your linker command. It is located together with other applications' shared modules in the subdirectory polymake/lib (relative to the location of your libpolymake.so).

I built this on a mac by now.
Just in case anyone else wants to do the same: It's not a graph.dylib but a graph.bundle (at least on my machine). I'm not too sure how to handle these bundles from a c++ program as one can't link against them like an ordinary library (as far as I know one has to load them at runtime). I was able to work around this by adding " -undefined dynamic_lookup" to the linker flags and not do anything with the graph.bundle file. Note that the "-Wl,--warn-unresolved-symbols" flag is not recognized by ld on a mac. Might not have been the most elegant way, but at least everything compiles and runs as it should.
Sören

With the latest snapshot of polymake this should now work without adding " -undefined dynamic_lookup".