parallel-netcdf-0.9.0, NEC SX

[Rob Ross]

No apologies necessary; thank you very much for this detailed report on 
the quirks of building on the SX platform!  We will look into these and 
try to come up with some solutions, although we will probably need to rely 
on you to actually test them :).

We hope you succumb to temptation and use the library!

Regards,

Rob

On Wed, 17 Sep 2003, rene.redler wrote:

> based on the parallel-netcdf-0.9.0 I downloaded on Monday this week
> I did some first tests on the SX using the SX make (obviously close to 
> the UNIX make)
> 
> When trying to process the files in src/libf in order to add them to the 
> already existing libpnetcdf.a (from src/lib) the dependencies cannot be 
> resolved properly. The make builds the .o file in src/libf but does not 
> update the already existing libpnetcdf.a, perhaps because it does not 
> consider the date of the .o files but takes the date of the .f files 
> instead (which are of course older then the libpnetcdf.a). The simple 
> workaround was to invoke the make for src/libf twice. I am not sure 
> whether I should provide another portable solution to you for the 
> Makefile.in in src/lib and /src/libf or whether you already have some 
> ideas how to eliminate this particular problem.
> 
> When trying to create the Fortran tests nf_test and fandc the loader 
> terminated with an error because of undefined symbols. Reason is that 
> already all routines are defined in pnetcdf.inc, while not all are
> implemented; and although declared as external the loader is expecting  
> them by default. To overcome this I had to specify a flag for the 
> compiler: -Wl"-h nodefs". I thought that this could be done by setting the 
> environment variable FFLAGS, but the Makefile in test/fandc does not use 
> FFLAGS at all and test/nf_test overwrites FFLAGS with something defined 
> elsewhere.
> 
> Taking this into account the Fortran tests fandc and nf_test succeeded.
> 
> Furthermore I noticed that pnetcdf.inc defines several routines nfmpi__* 
> which are probably not needed anymore and can perhaps be eliminated from 
> the pnetcdf.inc.
> 
> On the SX integer*1 does not exist which is correctly detected during 
> the configure step, and therefore no int1 interfaces are built. 
> Nevertheless they are defined in the pnetcdf.inc . Without the additional  
> flag (see above) this will remain a problem and requires the additional 
> flag when linking any application with the pnetcdf library. Such is not 
> required with the serial PnetCDF but unfortunately I don't know why. Any 
> ideas from your side?
> 
> Nevertheless it is tempting now to use your library for a parallel 
> application in the field of ocean modeling.
> 
> I am sorry for this long note.