The instructions were left in a confusing state by
68dc3f00 (Use bundled PolyLib by default).

If two evalues are in essence the same, but not identical,
e.g., when one of them has not been reduced, then evalue_level_cmp
could in some cases return -1 on both a given call and a call
with the arguments reversed, leading to an infinite recursion
on eadd_rev.

Arguably, the arguments should be reduced before calling
evalue_level_cmp, but there is no reason it should fail this
way if they are not.

Reported by Kostas Oikonomou

Apparently, Sun's compiler has a problem with those:

"/solapplic/sun-studio-11/SUNWspro/prod/include/CC/Cstd/./map", line 251: Error: Multiple declaration for std::map<const std::vector<int>, const _new__evalue*, std::less<const std::vector<int>>, std::allocator<std::pair<const std::vector<int>, const _new__evalue*>>>::insert(const std::pair<const std::vector<int>, const _new__evalue*>&).
"../../git/barvinok/laurent.cc", line 225:     Where: While specializing "std::map<const std::vector<int>, const _new__evalue*, std::less<const std::vector<int>>, std::allocator<std::pair<const std::vector<int>, const _new__evalue*>>>".
"../../git/barvinok/laurent.cc", line 225:     Where: Specialized in non-template code.

Sun's compiler complained about the old code:

"../../git/barvinok/genfun.cc", line 826: Error: Formal argument 3 of type extern "C" void(*)(void*,unsigned)* in call to __gmp_get_memory_functions(extern "C" void*(*)(unsigned)*, extern "C" void*(*)(void*,unsigned,unsigned)*, extern "C" void(*)(void*,unsigned)*) is being passed void(*)(void*,unsigned)*.

If GiNaC cannot be found, then libbarvinok simply references
libbarvinok-core, without adding any new code, but darwin's
ar apparently doesn't like it if no objects get added
to an archive.

(modulo GL_LINK_WARNING)

This change was missed in 562c5b13
(lattice_point.cc: multi_monom/lattice_points: return malloc'd evalue(s)).