I built this on a mac by now.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)....
Does this mean that something with my polymake installation is wrong?
Code: Select all
for (my $k=$HD->DIMS->[2]; $k<$HD->DIMS->[3]; ++$k) { print $HD->FACES->[$k] }
Code: Select all
print $p->FACETS;
With the latest snapshot of polymake this should now work without adding " -undefined dynamic_lookup".I built this on a mac by now.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)....
Does this mean that something with my polymake installation is wrong?
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