Glad to hear you could fix all of this.
There are more changes that are necessary for to make clang happy, though, and more warnings that are not critical but look as if it would be nice to fix them. E.g. polymake mixes "class" and "struct" when referring to a type. Harmless but trivial to fix.
Another problem is that sparse_proxy(_it)_base::iterator is protected in both types, which GCC accepts but triggers an error in clang. Looking at the code, I believe clang is right to complain.
Then there are some constructs GCC accepts but clang rejects -- and clang is right according to the C++ standard, so it's likely future GCC versions will eventually reject the code, too. Example: the definition of the ListValueOutput& operator<< (const X& x) method uses class Value before it is defined; in GCC this may be accepted, perhaps because the method is only instantiated *after* class Value has been declared, but this is a bug in GCC.
There are various more errors and warnings, which I recorded in a local git repository I made out of polymake 2.10. This also includes a patch which makes configure.pl a bit more clever about detecting compilers. I.e. it does not anymore assume that every compiler is either Intel C++, or else an (possible outdated) GCC version...
. But I am not sure whether these changes are still relevant / applicable for your secret development version of the code.