The parser for rulefiles has changed since the released version 2.10, so that the presented patch probably does not fit your code base. You would be on a safer side if you apply it to the current SVN snapshot, but if your solution works fine for you, you can surely leave it as is.

'make install-shared' does nothing else but copies the files from the unpacked tar ball to the final destination under /usr/local/... . If you directly patch the files at the destination, you obviously don't need any further copying, thus the 'make' step is superfluous (and impossible, because there...

I had no clue where to find the make-file necessary for applying the patch. Actually, this patch can be directly applied to the installed package as well, because it only modifies some perl modules and does not require any recompilation. You have to navigate into /usr/local/share/polymake (or whate...

Please try the attached patch. It should solve both problems you have encountered.
Apply it to the unpacked source tree:

Dear Raman, please look at first at the head line in the executable polymake main script. It should start with something like #!/usr/bin/arch . The architecture and perl interpreter path should exactly match those used during configuration and compilation phases (check the file build.darwin.XXX/conf...

It's not your fault, it looks like a bug in polymake. I suspect, it is caused by the fact that you are referring to options defined in another application, which is not imported into yours. How did you declare your application, did you put any IMPORT or USE commands in its rules? Would adding "...

First of all, I'm not lucky about the idea of introducing dependences between applications at the extension level. We should probably constrain the allowed appearances of USE and IMPORT commands to the primary main.rules of each application. Anyway, in your concrete case you are trying to establish ...

polymake just calls make. Whatever was configured at the very beginning and stored in build.*/conf.make, is then used for temporary compilations as well. If you have stored short program names there like gcc and g++, and install a new GCC version later, or just change your PATH, then surely you will...

Due to a mishap, the tarball exposed at the download page is still missing the latest patch for perl 5.14. It will be replaced very soon, please watch for changes. We apologize for the inconvenience.

A healthy gcc does not require such weird settings. I strongly suspect your installation is seriously corrupted, messed up, or just ill-born. I would suggest to install a clean gcc out of the box (4.3, 4.4, or 4.6) completely aside the system compiler, and then reconfigure and rebuild polymake from ...