Thanks for the answers lots of people sent me. However, I am still not
sure I got the answer.
I know that '-2' and '254' are just the signed and unsigned respresentation
of the same value. This might be just the 'bug'(?) in xdrtest. I would like
to know that ncdump does not have the same 'bug'. XDR passes the
binary test that means the data value will not change over different
platform because of the byte-order. However, Could the same '0xfe' shows
as '-2' in SUN but '254' in SGI when using the ncdump?
One more question, what's the reason that we need to unset TMPDIR on SGI
but not other platform?
When I set the environment TMPDIR, ftest fails with following messages:
ncendef: rename failed: Cross-device link
*** Termination code 139
I assume it has something to do with rename() system call which can not
rename file to different file system. However, checking the man page on
SUN and Ultrix shows the same restriction on the rename() call.
As for hdf-netcdf package, after I delete the testing on fortran subdirectory,
The package passes all other tests. The termination code is also 139 when
the ftest is run. However, there is no message about 'rename failed ...'
I think this problem might be related with the above TMPDIR problem although
this fails no matter whether TMPDIR is defined or not.
I suspect that has something to do with ncendef.
The termination code 139 should correspond to system error code 11 for SGI
which is:(except from 'man 2 intro')
11 EAGAIN Resource temporarily unavailable
1) A fork or sproc failed because the maximum number of processes
system wide {NPROC} was exceeded or the user exceeded their limit on
the number of child processes {CHILD_MAX}. 2) A system call failed
because of insufficient memory or swap space. Later calls to the
same routine may complete normally. 3) Some read system calls--
involving empty streams or locked files/records--with the O_NDELAY
flag set may return this error. See read(2).
Hope this help someone in UCAR/NCSA to sort out the problem.
Although netcdf does not seem to use structure/map on fortran code, SGI's
Fortran compiler has problem dealing with those on 4.0 and 4.0.1. At least
4.0.5 fix that problem.
Since netcdf package use 'assert', I think you might want to know that
using gcc compiler on SGI will have problem setting the exit code.
-Frank Chen
>> Keywords: 199210092023.AA16413 SGI IRIX XDR netCDF signed unsigned bytes
>
>Hi Frank,
>
>> When I built the netcdf package on SGI/IRIX 4.0.5, the message generated
>> during the testing of xdr is like this:
>>
>> [Delete ...]
>> Making `test' in /people_a/frank/netcdf/netcdf/xdr
>> 2c2
>> < bytes: 254 1 0 1 2 0 0 0
>> ---
>> > bytes: -2 1 0 1 2 0 0 0
>> *** XDR fails formatted test ***
>> The above differences are OK if small
>> *** XDR passes binary test ***
>> [Delete ...]
>>
>> Is the difference between '254' and '-2' **SMALL**?
> ...
>> Does ncdump affected when dealing with byte variables?
>> Does system default setting of signed/unsigned for char/byte
>> affect netcdf package?
>
>Until recently we had no support for IRIX because we had no access to an SGI
>workstation to test netCDF releases. Now we have done the port and it will
>be in the next release. I can't tell you when the next netCDF version will
>be ready. In the mean time, I've been told that our instructions for
>building netCDF under IRIX 4.0 in the current INSTALL file seem to work for
>other users:
>
> IRIX 4.0 on Silicon Graphics:
> unset TMPDIR [if it's set to a directory in another file system]
> make -k CC="cc -cckr" LIBTYPE=nonsharable OS=irix_4.0 \
> RANLIB=touch XDR_LD=-lsun all
> [for IRIX 3.3.2, use COPTS="-O -signed" instead of CC="cc -cckr"]
>
>except for a problem with running "xdrtest" having to do with signed versus
>unsigned characters. The failure of this last test is not significant; in
>the new release we've fixed the test.
>
>> P.S. Is there anyone successfully compile the hdf-netcdf stuff on
>> SGI/IRIX?(including fortran testing). It fails when calling tncredf.
>
>We haven't tried that yet, but thanks for pointing out the problem.
>
>--Russ
>
