>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.