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

[netCDF #OUH-534551]: Test ftst_vars4 failing on Solaris 10, GCC 4.2

Geoff,

The patch will definitely be included in the next release, because
I've just checked it in to our svn trunk.  However, the "next release" 
is the one in which we've split the netCDF Fortran and C++ libraries 
to be independent packages that depend on the netCDF C library having
already been installed.  So this will be in the netcdf-fortran-4.2.1
release.

The Fortran library is quicker and easier to install, now that it's
a separate release.  If the netCDF C library is installed as a shared
library (the default), say in /usr/local, then you just use the 
configure script that comes with the netcdf-fortran release, something
like:

  LD_LIBRARY_PATH=/usr/local/lib CPPFLAGS=-I/usr/local/include ./configure
  make check install

--Russ

> On 11/8/11 8:30 PM, Unidata netCDF Support wrote:
> > Hi Geoff,
> >
> >> Re-opening an admittedly old ticket - this diff shown below doesn't
> >> appear to have made it into NetCDF 4.1.3. I get a core dump on a sparcv9
> >> build using GCC 4.6. Applying that diff by hand on my test box gives me
> >> a STOP instead of a core dump, so it still doesn't fix the problem.
> >>
> >> It's strangely enough not a problem on Solaris 10 using the amd64 ISA -
> >> the test passes fine on that platform.
> > Unfortunately, we no longer have a Sparc v9 platform on which to test or 
> > debug
> > this problem, so I have to rely on users to test it.  Also, the developer 
> > who
> > wrote this test code for the F77 API has taken another position, so 
> > rewriting
> > the test is a problem.
> >
> > When it's convenient, could you try the following patch instead and let us 
> > know
> > if it still executes a STOP?  This works fine on our Linux x86_64 platforms:
> >
> > --- /tmp/netcdf-4.1.1/nf_test/ftst_vars4.F  2009-10-24 12:03:39.000000000 
> > +0200
> > +++ netcdf-4.1.1/nf_test/ftst_vars4.F       2010-09-20 14:19:55.216296221 
> > +0200
> > @@ -37,7 +37,7 @@
> >           integer data1(vlen_len), data1_in(vlen_len)
> >
> > C     These must be big enough to hold the stuct nc_vlen in netcdf.h.
> > -      integer vlen(10), vlen_in(10)
> > +     integer*8 vlen(10), vlen_in(10)
> >
> >   C     Loop indexes, and error handling.
> >          integer x, retval, index(1)
> >
> > --Russ
> >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: OUH-534551
> > Department: Support netCDF
> > Priority: Critical
> > Status: Closed
> >
> Hi Russ,
> 
> In this case, sparcv9 is the Instruction Set Architecture, or ISA. It's
> independent of the Solaris release, and is the basic 64-bit instruction
> set for SPARC processors.
> 
> OpenCSW builds for four different platforms by default. We try to
> provide packages for 32 bit and 64 bit processors on the Intel and SPARC
> releases of Solaris. At the moment, we are still building packages for
> Solaris 9, but this is changing soon as because Oracle is switching
> Solaris 9 to extended support mode. Solaris 9 is now maintainer
> best-effort, rather than required.
> 
> For each operating system release, we try to target the minimum
> processor required to run that version of the OS. Thus for 32 bit
> builds, we target Solaris 9 with the 386 ISA (Intel), and sparcv8
> (SPARC). For 64-bit builds, we target Solaris 9 with the amd64 ISA
> (Intel) and sparcv9 (SPARC). With the change to Solaris 10, our default
> ISA for Intel 32-bit builds will change to pentium-pro, and I think our
> SPARC ISA will get bumped to sparcv8+.
> 
> I say "try" above because individual package maintainers can override
> these basic ISAs if necessary. For example, parts of the NetCDF
> libraries fail to build on 32-bit Intel with the base 386 instruction
> set due to a bug with the GCC compiler (the _sync_fetch_and_add_4 bug),
> so I actually build NetCDF with the pentium-pro ISA. The same bug used
> to affect 32-bit SPARC builds with the basic sparcv8 ISA but this was
> fixed in GCC 4.6.something. Prior to that GCC bugfix I had to raise the
> base ISA to "sparcv8+".
> 
> With all of that business about ISAs and base platforms out of the way,
> back to the failing test. I'm not sure what caused the STOP problem, but
> it didn't happen on subsequent builds.
> 
> Thus, I believe the patch listed above works. I've tested it on 32 and
> 64 bit Intel and SPARC builds under Solaris 9 and 10, and it seems to
> work fine. If you could include it in the distribution (it's not there
> in 4.1.3), that would be great, as I could remove the manual patching
> from my build recipes.
> 
> Thanks!
> Geoff
> 
> 

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



Ticket Details
===================
Ticket ID: OUH-534551
Department: Support netCDF
Priority: Critical
Status: Closed