This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Santiago, >Date: Tue, 09 Dec 2003 12:02:52 -0500 >From: "Santiago Gasso'" <address@hidden> >Organization: NASA/GFSC >To: Steve Emmerson <address@hidden> >Subject: Re: 20031208: problems compiling large file netCDF on Sun Ultra-60 The above message contained the following: ... > >What is the absolute pathname of your f77(1) utility? > > ls opt/SUNWspro/bin/f77 > > I am running SunOS sunhsieh 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-60 > (Solaris 8 which is a 64bit OS). > > > >The netCDF package ensures that the "-xarch=v9" option is always > >specified on the C and Fortran compilation commands. The f77(1) command > >above doesn't have that option. > > > I do not understand this. My compiler does take that option. I tried > several combinations (always deleting the objects before recompiling): > FFLAGS= -xtarget=native64 -xarch=native64 , FFLAGS= -xtarget=ultra > -xarch=v9 and a number more (including the -PIC and Bstatic options) and > I always get the same error message. > > f77 -o farop_v13.exe main.o case15rad.o case234rad.o getsungeo.o > getphase2.o get3param.o readnaap.o readnogaps2.o interpsun.o interp.o > extscat.o raycross.o efftable.o waterabs.o handle_err.o > /export/home/ji/netcdf-3.5.0/lib/libnetcdf.a > ld: fatal: file main.o: wrong ELF class: ELFCLASS64 > ld: fatal: File processing errors. No output written to farop_v13.exe > make: *** [farop_v13.exe] Error 1 The architecture-specific options (e.g., "-xtarget", "-xarch") must be specified in the link-command as well as in the compilation-command. Have you tried something like this: f77 -xarch=v9 -o farop_v13.exe main.o case15rad.o case234rad.o \ getsungeo.o getphase2.o get3param.o readnaap.o readnogaps2.o \ interpsun.o interp.o extscat.o raycross.o efftable.o waterabs.o \ handle_err.o /export/home/ji/netcdf-3.5.0/lib/libnetcdf.a I would also not use the "-xtarget" option because it's unnecessary and would favor "-xarch=native64" over "-xarch=v9". > I did it and I found a couple of interesting things: My object files are > (compiled with -xtarget=native64 -xarch=native64) > > 77 sunhsieh% file *.o > case15rad.o: ELF 64-bit MSB relocatable SPARCV9 Version 1, UltraSPARC1 > Extensions Required ... > and my source files : > > > 78 sunhsieh% file *.f > case15rad.f: fortran program text > case234rad.f: fortran program text > efftable.f: fortran program text > extscat.f: fortran program text > faropsave.f: fortran program text > get3param.f: fortran program text > getphase2.f: fortran program text > getsungeo.f: fortran program text > handle_err.f: fortran program text > interp.f: fortran program text > interpsun.f: fortran program text > main.f: ascii text > raycross.f: fortran program text > readnaap.f: fortran program text > readnogaps2.f: fortran program text > waterabs.f: fortran program text > > note that the script main.f is labeled as ascii text , not fortran program. > Coincidentally, main.f object's file is the one the linker had problems > with. This script (main.f) does not contain any call to any netCDF library > , only 3 external subroutines do. I believe that file(1)'s inability to determine that "main.f" is a Fortran program is merely a coincidence and has nothing to do with your linking problem. > In addition, I found something else: the static libraries of my compiler > are 32-bits. See here: > > opt/SUNWspro/lib/CC4: directory > opt/SUNWspro/lib/dbxrc: assembler program text > opt/SUNWspro/lib/debugging.so: ELF 32-bit MSB dynamic lib SPARC Version 1, > dynamically linked, not stripped ... You must link 64-bit object modules against 64-bit libraries. This is why a 64-bit option must be specified on the link-command. > Given this, it seems to me there are two approaches: reinstall the fortran > compiler and make sure all libraries have the appropiate 32 or 63 bit > architecture 64-bit system runtime libraries should already be installed on your platform. > or reinstall the netCDF library in a 32-bit mode. > So, I am going to talk to our computer manager on this, but I will be great > if you have some advise, since he is not familiar with Suns and the F77 > compiler. > > Santiago Gasso' > > Goddard Earth Science and Technology Center > University of Maryland > > --------------------------------------------------------------------------------- > > > Contact info: > > Dr. Santiago Gasso' > Code 913 (If Fedex , DHL or UPS add: Bldg. 33, C311) > NASA/GSFC Phone: (301)614-6244 > Greenbelt, MD 20771 Fax : (301)614-6420/6307 > USA E-mail: address@hidden > --------------------------------------------------------------------------------- Regards, Steve Emmerson