Re: 20040830:32-bit versus 64-bit netCDF

Hi Vince,

> ... Yes I am saying we use 32 bit NETcdf with 64 bit
> pcm.  My theory is that we put 64 bits into NETcdf and it converts it
> to 32 bit on the otherside when we're writing and does the converse
> when we're reading.  It's a black box to me, BUT i know that we use
> LIBS=-L$(NCLIB) -lnetcdf_real4 $(MASS) on AIX systems
> LIBS=-lmpi -L/usr/local/lib32/r4i4 -lnetcdf  on IRIX systems

This contradicts my understanding of the use of 64-bit and 32-bit
objects on systems that support both.  I'm used to not being able to
link something compiled as a 64-bit object with a library compiled as
a 32-bit object.  For example, on Solaris, if I try to link a 64-bit
program with a library compiled for 32-bits, I get an error from the
compiler, like:

  ld: warning: file 
/home/russ/netcdf-3/build/buddy-36b3-64/lib/libnetcdf.a(attr.o): wrong ELF 
class: ELFCLASS64

and then a bunch of messages about undefined externals.

Similarly on AIX, if I try the same stunt, I don't get a warning, just
a bunch of undefined externals:

  ld: 0711-317 ERROR: Undefined symbol: .nc_inq_att
  ld: 0711-317 ERROR: Undefined symbol: .nc_get_att_text

I don't have access to the necessary libraries built on IRIX64, but my
experience there is the same.

Finally, there's this standards document for c89 that says you aren't
supposed to be able to mix objects compiled under different
programming models (4 models with 64-bit versus 32-bit pointers and
64-bit versus 32-bit file offsets):

  Portable applications must not attempt to link together object files
  compiled for different programming models. Applications must also be
  aware that binary data placed in shared memory or in files might not
  be recognised by applications built for other programming models.

  http://www.opengroup.org/onlinepubs/007908799/xcu/c89.html

So if you've been getting away with this, I'm surprised it works.

On the other hand, maybe I've misunderstood the question ...

--Russ