throwing aborts, or: libtool sucks, or: slink sucks even more
Hi everybody, The issue of the nasty crashes whenever something is thrown internally (as in .normal(), if the heuristic algorithm failed or in .series() for functions with poles) came up last week. Finally it is becoming clear what's happening. series(tgamma(x),x==0,1) crashed reproducibly when linked dynamically, either in ginsh, ginaccint or elsewhere. Let me explain what's happening. So I am no longer to blame. :-) 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. Libtool's documentation does have something to say about this:
[...] running the C++ compiler directly may lead to problems related with inter-library dependencies.
The conclusion is that libtool is not ready for general use for C++ libraries.[...]
Furthermore, you'd better find out, at configure time, what are the C++ Standard libraries that the C++ compiler will link in by default, and explicitly list them in the link command line. Hopefully, in the future, libtool will be able to do this job by itself.
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). Well, the day before yesterday they have released libtool 1.3.5 but that doesn't change much. 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). Happy hacking -rbk. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
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/>
participants (1)
-
Richard B. Kreckel