3.0.2 build failure on RHELv5.1

[John W. Eaton]

On 22-Sep-2008, Jeff Blaine wrote:

| John W. Eaton wrote:
| > On 22-Sep-2008, Jeff Blaine wrote:
| > 
| > | That's correct:
| > | 
| > | octave-3.0.2:beijing> grep ZLIB config.h
| > | /* Define if ZLIB is available. */
| > | #define HAVE_ZLIB 1
| > | #define HAVE_ZLIB_H 1
| > | octave-3.0.2:beijing>
| > | 
| > | It's possible there is some other zlib.h being included, but
| > | there is no reasonable explanation as to why.  For example:
| > | 
| > | octave-3.0.2:beijing> grep gzclearerr /usr/rcf/include/zlib.h
| > | octave-3.0.2:beijing>
| > | 
| > | However, I have nothing whatsoever in my shell's environment
| > | that suggests /usr/rcf anywhere.
| > | 
| > | octave-3.0.2:beijing> env | grep /usr/rcf
| > | octave-3.0.2:beijing>
| > 
| > Try the following in your Octave build directory:
| > 
| >   cd src
| >   make CXXFLAGS=-save-temps pic/c-file-ptr-stream.o
| > 
| > then look at the resulting c-file-ptr-stream.ii file (it will be in
| > the src directory, not the src/pic directory) and see if it gives you
| > any clues about why these symbols are not declared.  It should at
| > least tell you which zlib.h file is included and precisely what the
| > declaration for gzclearerr is, assuming it is there.
| > 
| > When I do this, I see
| > 
| >   # 1 "/usr/include/zlib.h" 1 3 4
| > 
| > in the .ii file at the point where zlib.h is included, and
| > 
| >   extern void gzclearerr (gzFile file);
| > 
| > later on in the file.  What happens on your system?
| > 
| > jwe
| 
| I see:
| 
|          # 1 "/usr/local/include/zlib.h" 1 3
| 
| And this is the same path as /usr/rcf/include/zlib.h (one
| is symlinked to another).
| 
| Configure is being a little too helpful on its own by
| searching /usr/local, which I don't want.

The configure script isn't directly searching /usr/local/include or
any other directory for header files.  It relies on the compiler to do
that.  If you compile a trivial C++ program with "g++ -v", it should
tell you what directories are searched by default.  For example, on my
system it prints

  $ g++ -v foo.cc
  Using built-in specs.
  Target: x86_64-linux-gnu
  Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
  Thread model: posix
  gcc version 4.3.1 (Debian 4.3.1-9) 
  COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
   /usr/lib/gcc/x86_64-linux-gnu/4.3.1/cc1plus -quiet -v -D_GNU_SOURCE foo.cc -quiet -dumpbase foo.cc -mtune=generic -auxbase foo -version -o /tmp/ccIzRuCV.s
  ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
  ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.3.1/../../../../x86_64-linux-gnu/include"
  ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
  #include "..." search starts here:
  #include <...> search starts here:
   /usr/include/c++/4.3
   /usr/include/c++/4.3/x86_64-linux-gnu
   /usr/include/c++/4.3/backward
   /usr/local/include
   /usr/lib/gcc/x86_64-linux-gnu/4.3.1/include
   /usr/lib/gcc/x86_64-linux-gnu/4.3.1/include-fixed
   /usr/include
  End of search list.
  [...]

As I recall, this is the way GCC is configured by default.

| I even see this in ChangeLog.1 from 1992 :)
| 
| ===================================================================
| Fri Dec  4 01:51:05 1992  John W. Eaton  (jwe at schoch.che.utexas.edu)
| 
|      * configure.in (INCDIRS): Don't include /usr/local/include.
|      (LIBDIRS): Don't include /usr/local/lib.
| ===================================================================

That is ancient history and I doubt that it is relevant here.

| I've now edited configure and changed ac_default_prefix to
| read "/tmp" instead of "/usr/local" and started a build.

I think that variable is the default installation prefix for Octave
itself and has nothing to do with where the compiler will find include
files.

jwe