throwing aborts, or: libtool sucks, or: slink sucks even more

[Richard B. 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 at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>