[Support #TIB-359748]: "make check" fails in NetCDF4

> Hi Ed (or whoever gets this email today),
>
> I'd be happy to submit a new bug report if necessary, but I just installed
> the final HDF5-1.8, and tried compiling the latest NetCDF4 snapshot, and got
> exactly the same errors that I described in the bug report associated with
> ticket TIB-359748.  I have my own work-around (changing #include <netcdf.h>
> to #include "netcdf.h" in all *.c files in the libsrc4 subdirectory), but
> since you suggested at one point that this was not an optimal solution, I
> thought I'd point out that this issue persists so that you might consider
 > re-opening the old ticket.  Let me know if you need any additional
> information.
>
> -Josh
>

Sorry Josh! My mistake. I had changed the main code files, but for some reason
forgot to change all the test files which included netcdf.h. Duh.

Anyway, it's fixed now and you can get the latest snapshot here and see if it
works for you:
http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/netcdf-4/

Also, the 1.8.0 HDF5 release won't do, you need to get the post-1.8.0 HDF5
snapshot from the netcdf-4 snapshot page.

I made the changes because I agree with you that this is the right thing to do
with the code.

But there is something I have never understood about this issue. I don't
believe that -I. is treated as a system directory. I just reread the gcc
pre-processor info pages and I see this:

GCC looks in several different places for headers.  On a normal Unix
system, if you do not instruct it otherwise, it will look for headers
requested with `#include <FILE>' in:

     /usr/local/include
     LIBDIR/gcc/TARGET/VERSION/include
     /usr/TARGET/include
     /usr/include

Later I see this:

   The `-isystem' command line option adds its argument to the list of
  directories to search for headers, just like `-I'.  Any headers found
  in that directory will be considered system headers.

   All directories named by `-isystem' are searched _after_ all
  directories named by `-I', no matter what their order was on the
  command line.  If the same directory is named by both `-I' and
  `-isystem', the `-I' option is ignored.  GCC provides an informative
  message when this occurs if `-v' is used.

But I am not seeing the -isystem option in either my output or yours.

So what is going on here?

Also, why are you seeing this and not me?

Something else is happening, and I can't figure out what it is. Could you run
gcc with the -v option to see if you get any useful warnings, as promised by
the documentation?

When I do this I see:
#include "..." search starts here:
#include <...> search starts here:
 .
 ..
 ../fortran
 ../libsrc
 /shecky/local/include
 /usr/local/include
 /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
 /usr/include
End of search list.

Which seems to indicate that "." will be searched first, before ../libsrc.

I have cleaned up the Makefile.am in this directory a bit during this process,
and I am testing that now...

Thanks,

Ed




Ticket Details
===================
Ticket ID: TIB-359748
Department: Support netCDF
Priority: Normal
Status: Open