[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #TEQ-670685]: error during LibMesh compile


> Sorry, I am unsure now of what I should try out.
> > Do you still get those two failures from running "make check"*after*
> > running the configure script.  If so, do you still see the same output
> > as you originally reported, including those unexpected strings?
> On 5/30/14 9:52 PM, Unidata netCDF Support wrote:
> > When you run either of these ncgen3 scripts (after setting a srcdir
> > environment variable to a path to the directory containing the ncgen3
> > sources), does the output you see still have "<http://c0"; strings in
> > it?
> You mean I should run run_tests.sh or run_nc4_tests.sh which I find in
> the source:
> /libmesh_root/contrib/netcdf/v4/ncgen3
> adding a path like this:set 
> PATH=$PATH:~/Desktop/libmesh_root/contrib/netcdf/v4/ncgen3/ .
> This only gives
> *** Testing ncgen3.
> *** creating classic file c0.nc from c0.cdl...
> ./run_tests.sh: line 8: ./ncgen3: No such file or directory
> Or should I make-run the executable in the "build" directory? This
> doesn't give any output...

No, I didn't mean to change your PATH environment variable, I meant to
set a "srcdir" environment variable to a path to the directory containing 
the ncgen3 sources.

However, rather than trying to explain the intricacies of getting just
that test to run in the build directory with the "srcdir" environment
variable, I'm going to recommend that you start over with the current
release of netCDF-C, version 4.3.2, and build and install that.  Then
I recommend that you build and install netCDF-Fortran, version 4.2, by
following the instructions we supply here:


The reason I'm recommending starting over is that it looks like you
are no longer having the problem you originally reported, in which
the failed output started:

  *** Testing ncgen3.
  *** creating classic file c0.nc <http://c0.nc> from c0.cdl...

But now, your output starts

> *** Testing ncgen3.
> *** creating classic file c0.nc from c0.cdl...

which no longer has the spurious "<http://c0.nc> " string you
originally reported.  So I'm guessing whatever caused that problem
is gone, so maybe the "make check" will complete normally, as it does
for us on OSX 10.9.3 using /usr/bin/cc and gfortran ...

I'm just running a test now on OSX-10.9.3 to make sure this combination
builds as I've claimed ...


Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu

Ticket Details
Ticket ID: TEQ-670685
Department: Support netCDF
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.