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

20031209: problems compiling large file netCDF on Sun Ultra-60

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