From owner-bug-octave at bevo dot che dot wisc dot edu  Fri Dec 20 04:23:59 1996
Subject: Re: 2.0 compilation problem
From: Francesco Potorti` <F dot Potorti at cnuce dot cnr dot it>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
CC: Octave bugs list <bug-octave at bevo dot che dot wisc dot edu>
Date: Fri, 20 Dec 96 11:24 MET

I reinstalled gcc.  Thanks for the RTFM tip.  I had missed the
bootstrap phase.  It would have been too simple if it was configure;
make; mmake install ...

Now gcc is hopefully correctly installed.  The warnings I spoke you
about have disappeared after I applied your two patches.

   The quick solution would probably be to delete the definition of NPOS
   in Octave's config.h file.  However, this shouldn't really be
   necessary.  If running Octave's configure with gcc properly installed
   still results in NPOS being defined in Octave's config.h file, can you
   try to find out why?
   
I rerun Octave's configuration after reinstalling gcc, and it defines
NPOS in config.h.  The reason is that

#include <string>

fails.  It appears that you assume gcc will look for string.h (I don't
know C++), but it won't.  Here is the trace of what happens:

--------- conftest.C -------
#line 2217 "configure"
#include "confdefs.h"
#include <string>
int main() {
size_t foo = NPOS
; return 0; }
----------------------------
sable$ c++ -c -v  conftest.C
 gcc -c -v conftest.C
Reading specs from /usr/users/pot/lib/gcc-lib/alpha-dec-osf3.0/2.7.2/specs
gcc version 2.7.2
 /usr/users/pot/lib/gcc-lib/alpha-dec-osf3.0/2.7.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=7 -Dunix -D__osf__ -D__alpha -D__alpha__ -D_LONGLONG -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__ -D__osf__ -D__alpha -D__alpha__ -D_LONGLONG -D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix -D__SYSTYPE_BSD -Asystem(unix) -Asystem(xpg4) -Acpu(alpha) -Amachine(alpha) -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C -D__LANGUAGE_C_PLUS_PLUS__ -D__LANGUAGE_C_PLUS_PLUS -D__cplusplus conftest.C /tmp/ccaaCipa.ii
GNU CPP version 2.7.2
#include "..." search starts here:
#include <...> search starts here:
 /usr/users/pot/lib/g++-include
 /usr/local/include
 /usr/users/pot/alpha-dec-osf3.0/include
 /usr/users/pot/lib/gcc-lib/alpha-dec-osf3.0/2.7.2/include
 /usr/include
End of search list.
configure:2218: string: No such file or directory
sable$ find ~ -name string.h
/usr/users/pot/gcc-2.7.2/include/g++/std/string.h
/usr/users/pot/gcc-2.7.2/include/string.h
/usr/users/pot/lib/gcc-lib/alpha-dec-osf3.0/2.7.2/include/g++/std/string.h
/usr/users/pot/lib/gcc-lib/alpha-dec-osf3.0/2.7.2/include/string.h
sable$ 


However, there are other problems that stop the compilation.  The
problem of files included without the .h suffix (is this a C++ usage?)
hits for other files too, like cassert, cstdlib, complex.  Moreover
iostream.h is not found.  Here is what a find gives:

sable$ find ~ /usr/include /usr/local/include -name iostream.h
/usr/users/pot/gcc-2.7.2/include/cxx/iostream.h
/usr/users/pot/gcc-2.7.2/include/g++/iostream.h
/usr/users/pot/lib/gcc-lib/alpha-dec-osf3.0/2.7.2/include/cxx/iostream.h
/usr/users/pot/lib/gcc-lib/alpha-dec-osf3.0/2.7.2/include/g++/iostream.h
/usr/include/cxx/iostream.h
/usr/include/g++/iostream.h


An interesting thing: while /usr/users/pot/lib/g++-include is
searched, it does not exist!  I also installed libg++-2.7.2, but
nothing changed.

Thanks.