Re: gcc-2.7.2 compilation

[Ulrich Eckhardt]

Hafeez wrote:
> I am having real trouble compiling this code
> http://www.cs.wisc.edu/~vganti/birchcode/codeHier/AttrProj.tgz
> The attachment shows errors when compiled using the current version of
> g++ in a i386-pc-solaris2.9.
> Seeing reference to gcc-2.7.2 in the Makefile of the code ...

2.7 is really ancient. I'm not sure that's all(just ported a few things
from 2.95 to standard C++), but here's a list you could check:
- iostream.h and similar headers of old iostreams, replacing with
<iostream> helps.
- lack of namespaces. 'using namespace std' after including the new headers
as a workaround, alternatively adding the necessary 'std::' prefixes.
- iostreams_with_assign. Used to be able to redirect streams, now replaced
by streambuffers and rdbuf() member of streams.
- a few of SGI's algorithms didn't make it into the standard or only in a
changed form. Needs manual tweaking.

> ...I downloaded it and compiled in my home directory. Then changed 
> the referenes of LIBDIR and INCLUDES to
> this installation .and ran with g++ for 2.7.2 then there are still
> errors (attached as well). Apparently, the installation of 2.7.2 does
> not create includes like iostream.h anywhere. I have installed
> --prefix=$HOME --with-local-prefix=$HOME

> Util.h:73: iostream.h: No such file or directory

Maybe you're just missing a standardlibrary, I seem to recall it used to be
separate from the compiler.

> warning: #warning This file includes at least one deprecated or
> antiquated header. Please consider using one of the 32 headers found
> in section 17.4.1.2 of the C++ standard. Examples include substituting
> the <X> header for the <X.h> header for C++ includes, or <sstream>
> instead of the deprecated header <strstream.h>. To disable this
> warning use -Wno-deprecated.

> global.h:43:9: warning: extra tokens at end of #endif directive

Those two should be trivial to fix.

> `/local.blondie.1/BIRCH/AttrProj/AttrProj.h', needed by
> `components.o'.  Stop.

Hmmm, this one's strange, but it's not a compiler error but rather one by
make. Maybe your two attempts with different compilers messed up
autogenerated dependency files?

Uli

-- 
http://gcc.gnu.org/faq.html
http://parashift.com/c++-faq-lite/