[ncl-install] Multiple definitions, undefined references while linking ncl

[Rick Grubin]

Hi Jan

> Since my last message I got around several compilation problems:
> 1) Missing triangle, as described in the installation guide

Do you now have the necessary source code, and is it compiling as  
expected?


> 2) I had to replace yy_current_buffer with YY_CURRENT_BUFFER_LVALUE  
> in ni/src/ncl/Symbol.h to work around an undefined reference  
> (related to my flex version again, I guess)

This is interesting; I've never seen this problem and can't find any  
reference to something similar in our help archives.  Would you
please send me a copy of your 'ncl.' file?


> 3) I had to make a symlink hdf -> . in HDF's include directory.  
> Some source files wanted to include <hdf/hdf.h>.

This issue, and your failing link below, is because of an incorrect  
installation of HDF.

With respect to the include file directory, the instructions  
explicitly state that when HDF is configured for building, it is  
necessary
to specify a distinct directory for the header files.  This is be  
sure that header files included with HDF don't conflict with header
files from other, necessary, external software.  Here's the relevant  
note from the NCL installation instructions (assuming that your
installation root for HDF is '/usr/local/include'):

Normally the HDF include files would get installed to /usr/local/ 
include. Since this will cause some netCDF include files to get  
overwritten, you must use the "--includedir" option to install the  
HDF include files to an "hdf" subdirectory.


> 4) I had to play with the order of -I options to put NetCDF before  
> HDF. Both provide netcdf.h, and only NetCDF's netcdf.h defines  
> NC_64BIT_OFFSET needed by some source file. This workaround was  
> possibly made necessary by the symlink I created in 3).

It's quite possible that what you did in #3 above created this  
issue.  There are some files within the HDF and netCDF installations
that conflict with each other -- HDF includes its own implementation  
of netCDF, and as such, HDF must be told to configure/build
differently than its default so that, further down the "build NCL"  
chain, the two do not conflict.  That's why configuring and installing
HDF per the instructions on the NCL installation site are important  
to follow.


> 5) I had to hack Makefiles of ictrans and ncl to add an -L option  
> and -l's for pgf90 runtime libraries. I think this is because I'm  
> using pgf90 and gcc together.

Having to modify these makefiles may indicate that your NCL  
configuration file is not properly set up.  Would you please forward
a copy of your configuration file (located in:  /dir/path/to/NCL/ 
source/config/LINUX)?


>  I'm now stuck again while trying to link ncl. The failing command  
> line is
>
> gcc -ansi -fPIC -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -O -Wl,-- 
> export-dynamic   -o ncl Ncl.o [...]
>
> A representative selection of error messages is:
>
> /home/VO_SW_DIR/wisent/HDF4.2r2/lib/libmfhdf.a(globdef.o)(.data 
> +0x8): multiple definition of `ncopts'
> /home/VO_SW_DIR/wisent/netcdf-3.6.2/lib/libnetcdf.a(v2i.o)(.data 
> +0x0): first defined here
> /home/VO_SW_DIR/wisent/HDF4.2r2/lib/libmfhdf.a(globdef.o)(.bss 
> +0x0): multiple definition of `ncerr'
> /home/VO_SW_DIR/wisent/netcdf-3.6.2/lib/libnetcdf.a(v2i.o)(.bss 
> +0x0): first defined here
> NclHDF.o(.text+0x62): In function `HDFGetAttrVal':
> : undefined reference to `sd_ncattget'
> NclHDF.o(.text+0xc0): In function `HDFGetAttrVal':
> : undefined reference to `sd_ncattget'
> NclHDF.o(.text+0xff9): In function `HDFOpenFile':
> : undefined reference to `sd_ncopen'

These messages indicate an HDF built improperly; that is, with its  
own version of netCDF that will conflict with netCDF itself
when NCL tries to link.  As already noted, you'll need to reconfigure  
and reinstall HDF.

The install instructions for NCL are indeed complicated and lengthy;  
for that, we do apologize.  We are always glad to hear of
improvements we can make to the instructions to make experiences like  
yours a better one.

----	
Rick Grubin      NCAR/TDD/CISL/VETS
Visualization + Enabling Technologies
grubin at ucar.edu             303.497.1832