20040507: problems linking my sat_archive progr with libmcidas.a

>From: Marek Kmiecik <address@hidden>
>Organization: SUNYA/CESTM
>Keywords: 200405072017.i47KHdtK011466 McIDAS libmcidas.a link

Marek,

>I have 2 Sun machines (sunblade100 and little older ultra10) 
>It looks like on my primary machine (sunblade100) things are O'K.
>But I'm having an awkward problem in my secondary machine.
>Both machines are solaris2.9, the same revision, they both are using
>the same c compiler which is installed on the remote server (Sun C compiler).
>The same with g++,f77,e.t.c. stuff..., they both have most recently
>updated patches,e.t.c.
>Yet on the second machine while trying to compile my archiving program 
>the task, which require linking it with libmcidas.a library,
>I do have the following complain:
>f77 -o sat-pixel -I/Satellite/srccode/lib -fast -DSUNISDOWN sat-pixel.o 
>sunaev2.o grid.o -L/Satellite/srccode/lib -L/home/mcidas/lib -lmcidas -lutil -
> lm 
>-lsocket -lnsl
>f77: Warning: -xarch=native has been explicitly specified, or implicitly 
>specified by a macro option, -xarch=native on this architecture implies 
>-xarch=v8plusa which generates code that does not run on pre UltraSPARC 
>processors
>Undefined                       first referenced
> symbol                             in file
>__s_wsFi_pv                         /home/mcidas/lib/libmcidas.a(nv1tanc.o)
>__do_f_in_pv                        /home/mcidas/lib/libmcidas.a(ddeservf.o)
>__e_wsfi_pv                         /home/mcidas/lib/libmcidas.a(nv1tanc.o)
>__f_open_nv                         /home/mcidas/lib/libmcidas.a(ddeservf.o)
>__s_wsle_pv                         /home/mcidas/lib/libmcidas.a(gms5_nav.o)
>__s_wsFe_pv                         /home/mcidas/lib/libmcidas.a(gms5_nav.o)
>__e_wsfe_pv                         /home/mcidas/lib/libmcidas.a(gms5_nav.o)
>__do_l_out_pv                       /home/mcidas/lib/libmcidas.a(gms5_nav.o)
>__do_f_out_pv                       /home/mcidas/lib/libmcidas.a(nv1tanc.o)
>__s_rsFe_pv                         /home/mcidas/lib/libmcidas.a(ddeservf.o)
>__e_rsfe_pv                         /home/mcidas/lib/libmcidas.a(ddeservf.o)
>__e_wsle_pv                         /home/mcidas/lib/libmcidas.a(gms5_nav.o)
>ld: fatal: Symbol referencing errors. No output written to sat-pixel
>*** Error code 1
>make: Fatal error: Command failed for target `sat-pixel'

The entry points that are not being found can be found in libF77.
I am suspicious that the warning you are getting:

  f77: Warning: -xarch=native has been explicitly specified, or implicitly
  specified by a macro option, -xarch=native on this architecture implies
  -xarch=v8plusa which generates code that does not run on pre UltraSPARC

may have something to do with the link failure.  Then again, the problem
may be in the location of the Sun Fortran libraries on your second machine.
Are they installed in a standard location?  Or, are they installed
in a location that is not searched by default by 'ld' when run from
'f77'.

As a comparison for your f77 line that is supposed to link sat-pixel,
here is the output from ~mcidas/mcidas2003/src/makelog on one of our
Sun Solaris SPARC 5.9 system with the WS7.0 Sun compilers for a routine
that links in nv1tanc.o:

f77 -s -O -o imgmag.k main.o imgmag.o -L. -R/usr/dt/lib -L/usr/dt/lib -R/usr/ope
nwin/lib -L/usr/openwin/lib -R/usr/local/lib -L/usr/local/lib -R/opt/SUNWspro/li
b -L/opt/SUNWspro/lib -lmcidas -lgen -lsocket -lnsl -lm

Notice how the link invocation is explicit in searching the Sun compiler
libraries (installed in /opt/SUNWspro/lib on our systems).

>Do you have any suggestion on what's causing the problem and (even more 
>important) how to fix it?

I suggest adding explict search of the directory your Sun Fortran compiler
libraries are installed in to your 'f77' invocation:

f77 -o sat-pixel -I/Satellite/srccode/lib -fast -DSUNISDOWN sat-pixel.o 
sunaev2.o grid.o -L/Satellite/srccode/lib -L/opt/SUNWspro/lib 
-L/home/mcidas/lib -lmcidas -lutil -lm -lsocket -lnsl

>I built mcidias software on both machines separately. I'm attaching
>2 logfiles, which are the output from "make all" command during
>installation., one, makelog which was generated automatically,
>and the other one, make_all.log, which was the stderr and stdout
>redirected to. 
>I have a feeling that the problem above may have something to do with
>this complain:
>......................................................................
>checking for g++... g++
>checking C++ compiler "g++"... configure: warning: g++ failed on test program
>configure: warning: Could not find working C++ compiler
>configure: warning: Setting CXX to the empty string
>configure: warning: The C++ interface will not be built
>checking how to run the C preprocessor... 
>/asrcserv1/opt/Forte6u2/SUNWspro/bin/cc -E
>configure: warning: Fortran-77 compiler is explicitly null
>configure: warning: The Fortran-77 interface will not be built

No, your problem is not related to this.  What is happening here is
'configure' for the netCDF part of the build has not been told
to _not_ build the C++ interface.  Since the C++ netCDF interface (and
F90 interface) is not used by McIDAS, we suggest not building it.
This is done by specifying:

CXX=""
F90=""

before starting the McIDAS build.

The list of environment variables that we suggest setting before you
start your McIDAS build can be found in:

McIDAS HomePage:
http://my.unidata.ucar.edu/content/software/mcidas
  Installation and Configuration
  http://my.unidata.ucar.edu/content/software/mcidas/2003/index.html
    Build, Test, Install -X
    http://my.unidata.ucar.edu/content/software/mcidas/2003/mcx/make_mcx.html
      Review System-specific Notes and Warnings
      
http://my.unidata.ucar.edu/content/software/mcidas/2003/mcx/warnings_mcx.html


>.......................................................................
>But both machines are using the same c,fortran,gcc,..., software,
>which is in the same location. And the other (sunblade100) machine doesn't mak
> e
>this complain and program does compile fine. Also, I noticed that 
>the library libnetcdf_c++.a was built on my sunblade machine,
>but not on ultra1, the one I'm having problem with.
>I even tried to copy libmcidas.a from the machine where compiling
>went fine to the one I'm having problem with, and then link my archiving
>program with it during compilation. The same complain as above remains.
>Thanks again for any suggestions, how to fix the problem.
>                                           -Marek Kmiecik
>                                            
>------------------------------------------------------------
>| MAREK KMIECIK                                            |   
>| Scientific Programmer                                    |
>| State University of New York at Albany ASRC-CESTM        |
>| 251 Fuller Rd.                                           |
>| Albany, NY 12203                                         |
>|                                                          |
>| address@hidden                           |
>| Tel: o(518)437-8719  h(518)869-4617  Fax: (518)437-8758  |
>| http://lunch.asrc.cestm.albany.edu/~marek                | 
>------------------------------------------------------------

Cheers,

Tom Yoksas
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.