Somehow, Bruno's answer didn't make it into the list. I forward it herewith:
Richard Kreckel writes:
GiNaC 0.6.1 got an updated libtool from FSF (1.3.4 instead of 1.3.3) and that libtool has changed it's behaviour for linking: $ libtool --mode=link c++ ... uses $CC for linking instead of c++, as it used to be.
Like you, I consider this a bug.
Libtool's documentation does have something to say about this:
The conclusion is that libtool is not ready for general use for C++ libraries. You should avoid any global or static variable initializations that would cause an "initializer element is not constant" error if you compiled them with a standard C compiler.
Ha! CLN is full of such static variable initializations.
I am somewhat clueless what those `problems related with inter-library dependencies' might be (there seems to be a gap in the mailing list archives).
They probably mean the order of initialization of static initializers. Precisely the thing that cln's CL_REQUIRE solves.
Anyhow, the trouble starts only when you use jurrasic compilers. And Debian/Slink does precisely this: gcc (used for linking) is 2.7.2.3 while c++ (used for compiling) is 2.91.60. Makes the solution pretty obvious: Just exporting CC=egcc prior to configuring solves all problems. Big deal. Or upgrading to Potato (if they manage to release it some lucky day).
Therefore, if I were you, I'd do three things:
- Patch the local copy of ltmain.sh to use the passed command, not $CC, in link mode.
- Tell in the documentation that $CC and $CXX should fit together, i.e. if one is gcc-x.y then the other should be g++-x.y.
- Tell in the documentation that g++ 2.7.x won't work because it doesn't have working exception support.
Bruno
Update: Patching ltmain.sh is probably unnecessary. The systems where this happened are Debian/Slink with a patched egcs, since the original from Debian isn't able to parse CLN-headers anyhow (thanks to some people at Debian who broke it, the upstream versions are all fine). It doesn't strike CLN anyhow, not even while linking tests and benchmarks since there libtool decides to use c++, which is fine. It only hurts when exceptions are thrown inside a library. I'll aplly patch 2, then. :-) Regards -richy. PS: I guess to `throw' an exception stems from to `throw up'. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>