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

20011229: McIDAS7.8-04



>From: James Frysinger <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 LDM binary install

Jim,

re: look in makelog to see why convdlm did not get built

>I pulled makelog up into kedit and did a search on convdlm. Here's what I 
>got:
>
>.....at the very top of the file:
>./mccomp -vendor -I. -I../netcdf/libsrc -I../jpeg -I../zlib -c convdlmc.c
>rm -f convdlmc.o
>gcc -c -O -ansi -D_GNU_SOURCE -I/usr/X11R6/include -I. -I../netcdf/libsrc 
>-I../jpeg -I../zlib convdlmc.c
>compile        convdlmc.c:             done
>./mccomp -vendor -I. -I../netcdf/libsrc -I../jpeg -I../zlib -c convdlmf.f
>rm -f convdlmf.o
>mcfc -c -I. -I../netcdf/libsrc -I../jpeg -I../zlib convdlmf.f
>convdlmf.f:
>   convdlm:
>   nchars:
>   len_trim:
>compile        convdlmf.f:             done
>./mccomp -s -vendor -o convdlm convdlmc.o convdlmf.o
>mcfc -s -o convdlm convdlmc.o convdlmf.o -L/usr/local/lib -L/usr/X11R6/lib 
>-lf2c -ldl -lm
>/usr/lib/libf2c.so: undefined reference to `MAIN__'
>collect2: ld returned 1 exit status
>link   convdlm:                done

OK, so now we know why convdlm did not get linked: the linker was trying
to use the shared f2c library, libf2c.so.  This library does not contain
the MAIN__ entry point that is needed, so the link fails.  This is
addressed in the Notes and Warnings document of the online McIDAS
web pages:

http://www.unidata.ucar.edu/packages/mcidas/780/mcx/warnings_mcx.html

under the 'gcc/f2c Users' link which notes:

  use the static f2c library, libf2c.a, when linking
  
       You need to link against the static f2c library, libf2c.a, since
       the shared version does not contain the needed entry point
       MAIN__.
  
   ...
  
  Since one must link against the static f2c library, libf2c.a, one
  should be aware of the following procedure:
  
  As root: 
  
       Type: mkdir /usr/local/lib
       Type: ln -s /usr/lib/libf2c.a /usr/local/lib/libf2c.a
  
  As the user mcidas: 
  
  Define the environment variable LD_LIBRARY_PATH so that the
  /user/local/lib directory is searched before others when programs are
  linked. For C-shell users, LD_LIBRARY_PATH would be set in .cshrc as
  follows:
  
       Type: cd ~mcidas
  
       Edit .chsrc and add:
  
       setenv LD_LIBRARY_PATH /usr/local/lib:/lib:/usr/lib
  
  After modifying .cshrc, make sure to make the changes active in your
  session:
  
       Type: source .cshrc


Now, it may well be the case that the SuSE distribution comes with
the GNU Fortran compiler, g77.  If so, I would assume that it would get
installed in the same directory as gcc so that if:

which gcc

works then:

which g77

should also work.  If this is the case, I recommend that you switch to
use of the gcc/g77 combination for building McIDAS.  This capability,
after all, was one of the biggest reasons for the 7.804 addendum.

To use g77, you will need to:

1) edit makefile and change:

VENDOR            = -vendor
# VENDOR          = -gcc
# VENDOR          = -g77

to:

# VENDOR          = -vendor
# VENDOR          = -gcc
VENDOR            = -g77

2) edit .cshrc and modify the defines of CC, CPPFLAGS, etc. for use of
   gcc/g77.  The defines will end up looking like:

# -- GNU gcc and g77 --
setenv CC gcc
setenv CPPFLAGS "-DNDEBUG -Df2cFortran"
setenv CFLAGS -O
setenv FC g77
setenv FFLAGS "-O -Wuninitialized -fno-automatic"
setenv CXX

3) after making the changes in .cshrc, you must source it to make the
   changes active:

source .cshrc

4) finally, restart your build after clobbering all previous compile output:

cd mcidas7.8/src
make clobber
make all

Taking this route allows you to avoid having to setup the static libf2c.a
library as discussed in Notes and Warnings.  It should be a smoother ride
from here.

>By the way, I used the new distribution, SuSE 7.3, to rebuild my system>
>The kernel here is 2.4.10, but that should have no effect on the build. 
>Libraries, maybe?

The problem is, indeed, a library one, but it is a known problem and has
a well documented workaround.

Tom


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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.