GiNaC build error with gcc 3.0 prerelease

[Richard B. Kreckel]

Hi George,

On Tue, 15 May 2001, george moudry wrote:
> I installed the "2.96" version because I am using the java front end (gcj).
> SuSE 7.1 personal did not come with gcj, so I grabbed this strange version 
> from rpmfind.net.
> 
> Today, I grabbed a new gcc version from 
> http://www.codesourcery.com/gcc-snapshots,
> but the GiNaC build still fails - in a different place. 

More below...

> Instead of the build, would you know where I can find the RPM?

Er, what?  The URL I sent you has 3 GiNaC RPMs, one for source, one for
binary and one for devel.  They were, however, built on RedHat.  Your
mileage may vary of course.

> thanks, george
> 
> PS. in case someone is interested in results of compilation with gcc pre-3.0,
> here is gcc version and ginac build error:
> 
> ###################################################
> gcc -v
>   Reading specs from /usr/local/bin/../lib/gcc-lib/i386-pc-linux-gnu/3.0/specs
>   Configured with: ../configure --prefix=/tmp/gcc-20010514-root/usr/local   
> --enable-shared --enable-threads --disable-checking i386-pc-linux-gnu :   
> (reconfigured)
>   Thread model: posix
>   gcc version 3.0 20010514 (prerelease)
> 
> ###################################################
> make[2]: Entering directory `/home/gg/down2/math/GiNaC-0.8.3/ginac'
> /bin/sh ../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I..   
> -I/usr/local/include  -g -O2 -c numeric.cpp
> rm -f .libs/numeric.lo
> c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -g -O2 -c numeric.cpp  
> -fPIC -DPIC -o .libs/numeric.lo
> /usr/local/include/g++-v3/bits/stl_construct.h: In function `void
>    std::_Construct(_T1*, const _T2&) [with _T1 = cln::cl_RA, _T2 =
>    cln::cl_RA]':
> numeric.cpp:100:   instantiated from here
> /usr/local/include/g++-v3/bits/stl_construct.h:48: no matching function for
>    call to `cln::cl_RA::operator new(unsigned int, void*&)'
> /usr/local/include/cln/rational_class.h:35: candidates are: static void*
>    cln::cl_RA::operator new(unsigned int)
> /usr/local/include/cln/rational_class.h:36:                 static void*
>    cln::cl_RA::operator new(unsigned int, cln::cl_RA*)
> make[2]: *** [numeric.lo] Error 1
> make[2]: Leaving directory `/home/gg/down2/math/GiNaC-0.8.3/ginac'

Ah, this is a particularly annoying "feature" of C++!  Since libstdc++-v3
we need that member operator new(uint, void*) now in all of CLN's classes
in order to instantiate STL containers with them.  Which means that
unfortunately we have some less compile-time checking for type-safety.  
This is one of the dark sides of C++:  In lesson one you learn that you
can overload on function arguments.  In lesson two you learn that you can
derive classes from other classes, inheriting their public/protected
members.  And then you learn that overloaded functions are not at all
inherited once you specify one other such function with a different
signature in the derived class.  Every programmer is bitten by this at
least once in his/her life.  I was even hit twice: had to realize first
that the problem is the same for overloaded operator member functions...  
:-(

You need to check out the current CLN from CVS.  It fixes this problem.
Apart from that it nothing significant has changed in CLN 1.1.1.  It's
just meant to be a bugfix release for the new GCC.  But I am waiting with
the release till GCC 3.0 has really hit the streets so I can be 100%
certain that it works.  Here is how to access CLN's CVS repository:
$ cvs -d :pserver:anoncvs at cvsthep.physik.uni-mainz.de:/home/cvs login
enter the password `anoncvs'
$ cvs -d :pserver:anoncvs at cvsthep.physik.uni-mainz.de:/home/cvs -z 9 co cln

Regards
    -richy.
-- 
Richard Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>


-
To UNSUBSCRIBE, email to ginac-list at ginac.de with a subject of "unsubscribe".