[Met_help] Problem with running the make script for METv0.9

John Halley Gotway johnhg at rap.ucar.edu
Mon Oct 1 14:56:07 MDT 2007


Helmut,

It still looks like there's an issue getting the MET code to link to the NetCDF library.

There are a couple of things you could do to try to debug that.

First, you could make sure that the NetCDF library archive file looks OK.  The tool "nm" (on my system, and hopefully on Solaris as well) can be used to dump the contents of a library archive file.
So first locate the file "libnetcdf_c++.a" in your netCDF distribution.  And try: nm libnetcdf_c++.a

This will list all of the symbols defined in that library archive file.  And you can use grep to pick out and make sure specific ones are there.  So: nm libnetcdf_c++.a | grep is_valid
Will look for symbols containing the function name is_valid.  Now there will likely be some compiler "garbage" characters before and/or after the is_valid symbol, but that's getting beyond my
expertise.  But if "is_valid" is not defined in your file "libnetcdf_c++.a" then you still have troubles with your netCDF library.

And when you compile MET, you could try turning on some debug trace for the linker.  You'll have to look at the man page for the compiler (g++) and the linker (ld on my system) to figure out exactly
what options to use.

In my top-level MET Makefile, I changed the Flags lines as follows:
FROM: FLAGS = -g -Wall -Wshadow -static
TO:   FLAGS = -g -Wall -Wshadow -static -Xlinker -t

This passes the "-t" option on to the linker, which turns on trace output for the linker.  Then you could see which netCDF you're linking to, to make sure you're actually linking to the version that
you think you are rather than some other version of netCDF on your system.  You can look at the other compiler and linker options on their man pages to look for others that might help as well.

Sorry I can't be of more help.

John

Helmut Berie wrote:
> Hi John,
> 
> I tried again today. Some way through mi attempts I realized that as a
> matter of fact I was using the standard C compiler when compiling netcdf
> so I ensured that I was using gcc/g++ by setting the  environment
> variables accordingly before running configure (I guess I mentioned
> before that I was/am not very familiar with all of this ...). Well
> anyway now I am somewhat confident that netcdf is built with the same
> compiler that I try to built MET with.
> 
> But still I receive the following message when compiling
> 
>    *** Making pcp_combine application ***
> 
> 
>    /usr/local/bin/g++ -o pcp_combine pcp_combine.cc \
>    -g -Wall -Wshadow -static  -DMET_BASE=\"/mnt/geog/gaia/bak41/METv0.9\" \
>    -I../../lib -I/mnt/geog/gaia/bak41/netcdf-built/include \
>    -L../../lib -L/mnt/geog/gaia/bak41/netcdf-built/lib \
>    -lvx_met_util -lvx_grib_classes -lvx_wrfdata -lvx_data_grids
>    -lvx_nav -lvx_cal \
>    -lvx_math -lvx_util -lm -lnetcdf_c++ -lnetcdf
>    ../../lib/vx_grib_classes/grib_strings.h:27: warning: 'missing_str'
>    defined but
>    not used
>    ../../lib/vx_grib_classes/grib_strings.h:45: warning:
>    'grib_code_list' defined b
>    ut not used
>    ../../lib/vx_grib_classes/grib_strings.h:77: warning:
>    'grib_code_list_str' defin
>    ed but not used
>    ../../lib/vx_grib_classes/grib_strings.h:341: warning:
>    'grib_level_list' defined
>     but not used
>    ../../lib/vx_grib_classes/grib_strings.h:360: warning:
>    'grib_level_flag' defined
>     but not used
>    ../../lib/vx_grib_classes/grib_strings.h:374: warning:
>    'grib_level_list_str' def
>    ined but not used
>    ../../lib/vx_wrfdata/vx_wrfdata.h:41: warning: 'wrfdata_magic'
>    defined but not u
>    sed
>    ../../lib/vx_wrfdata/vx_wrfdata.h:64: warning: 'thresh_type_str'
>    defined but not
>     used
>    ../../lib/vx_wrfdata/vx_wrfdata.h:85: warning: 'step_direction_str'
>    defined but
>    not used
>    ../../lib/vx_met_util/read_grib.h:41: warning: 'two_to_one_grib'
>    defined but not
>     used
>    Undefined                       first referenced
>     symbol                             in file
>    NcFile::is_valid() const            /var/tmp//ccTyqg51.o
>    NcVar::put(float const*, long, long, long, long,
>    long)/var/tmp//ccTyqg51.o
>    NcFile::add_att(char const*, char const*)/var/tmp//ccTyqg51.o
>    NcFile::close()                     /var/tmp//ccTyqg51.o
>    NcVar::add_att(char const*, float)  /var/tmp//ccTyqg51.o
>    NcVar::add_att(char const*, long)   /var/tmp//ccTyqg51.o
>    NcFile::NcFile(char const*, NcFile::FileMode, unsigned int*,
>    unsigned int, NcFil
>    e::FileFormat)/var/tmp//ccTyqg51.o
>    NcVar::add_att(char const*, char const*)/var/tmp//ccTyqg51.o
>    ld: fatal: Symbol referencing errors. No output written to pcp_combine
>    collect2: ld returned 1 exit status
>    make[3]: *** [pcp_combine] Error 1
>    make[2]: *** [all] Error 2
>    make[1]: *** [targets] Error 2
>    make: *** [all] Error 2
> 
> <cid:part1.05040402.00080007 at canterbury.ac.nz>
> And this allthough I am using a separate target folder for the netcdf
> compilation output. I have checked that all the mentioned files in the
> MET Makefile are found in the respective folders and have a current
> timestamp.
> 
> Do you have any further suggestions ?
> 
> Many thanks in advance.
> 
> Helmut Berié
> 
> 
> John Halley Gotway wrote:
>> Helmut,
>>
>> Sorry for not getting back with you sooner.
>>
>> I spoke with another software engineer here, and we think we have a
>> good guess at what's going on.  It was a good idea to try to build
>> your own version of NetCDF, making sure to use the GNU compilers
>> that you're using for building MET.
>>
>> The linker is looking in two directories for the NetCDF library
>> archive files.  It's looking in
>> /mnt/geog/gaia/bak41/netcdf-3.6.2/libsrc and
>> /mnt/geog/gaia/bak41/netcdf-3.6.2/cxx (set in the MET
>> top-level Makefile) for the files libnetcdf.a and libnetcdf_c++.a.  So
>> please check that those files are present in those directories.  In
>> the 3.6.2 version of netCDF we have here, those files are NOT
>> present in those directories, but instead, they'd be found on your
>> system in:
>> /mnt/geog/gaia/bak41/netcdf-3.6.2/libsrc/.libs
>> /mnt/geog/gaia/bak41/netcdf-3.6.2/cxx/.libs
>>
>> From the netcdf-3.6.2 directory you could execute the find command->
>> find ./ -name '*.a'
>>
>> It may be the case that if you do a "make install" for the netCDF
>> libraries, you could choose where to install those library archive
>> files.  Or you could probably just modify the MET top-level
>> Makefile to look in those directories.  For example,
>> NETCDF_LIBS  = -L$(NETCDF_BASE)/src/libsrc/.libs
>> -L$(NETCDF_BASE)/src/cxx/.libs
>>
>> Hopefully the linker will then find the definitions for those NetCDF
>> functions, and MET will continue to compile.
>>
>> Please let me know if this does the trick for you and what the next
>> issue that arises happens to be.
>>
>> Thanks,
>> John
>>
>>
>> Helmut Berie wrote:
>>  
>>> Hi John,
>>>
>>> I added one more include file in the filevx_wrfdata.cc then the library
>>> did compile.
>>>
>>> After that the compile for the library succeeded. So it was the missing
>>> declaration for the open function.
>>>
>>> Then the next problem came up with the compilation of  pcp_combine.
>>> The error message is given below
>>> *** Making pcp_combine application ***
>>>
>>>
>>> /usr/local/bin/g++ -o pcp_combine pcp_combine.cc \
>>> -g -Wall -Wshadow -static  -DMET_BASE=\"/mnt/geog/gaia/bak41/METv0.9\" \
>>> -I../../lib -I/mnt/geog/gaia/bak41/netcdf-3.6.2/cxx \
>>> -L../../lib -L/mnt/geog/gaia/bak41/netcdf-3.6.2/libsrc
>>> -L/mnt/geog/gaia/bak41/netcdf-3.6.2/cxx \
>>> -lvx_met_util -lvx_grib_classes -lvx_wrfdata -lvx_data_grids -lvx_nav
>>> -lvx_cal \
>>> -lvx_math -lvx_util -lm -lnetcdf_c++ -lnetcdf
>>> ../../lib/vx_grib_classes/grib_strings.h:27: warning: 'missing_str'
>>> defined but not used
>>> ../../lib/vx_grib_classes/grib_strings.h:45: warning: 'grib_code_list'
>>> defined but not used
>>> ../../lib/vx_grib_classes/grib_strings.h:77: warning:
>>> 'grib_code_list_str' defined but not used
>>> ../../lib/vx_grib_classes/grib_strings.h:341: warning: 'grib_level_list'
>>> defined but not used
>>> ../../lib/vx_grib_classes/grib_strings.h:360: warning: 'grib_level_flag'
>>> defined but not used
>>> ../../lib/vx_grib_classes/grib_strings.h:374: warning:
>>> 'grib_level_list_str' defined but not used
>>> ../../lib/vx_wrfdata/vx_wrfdata.h:41: warning: 'wrfdata_magic' defined
>>> but not used
>>> ../../lib/vx_wrfdata/vx_wrfdata.h:64: warning: 'thresh_type_str' defined
>>> but not used
>>> ../../lib/vx_wrfdata/vx_wrfdata.h:85: warning: 'step_direction_str'
>>> defined but not used
>>> ../../lib/vx_met_util/read_grib.h:41: warning: 'two_to_one_grib' defined
>>> but not used
>>> Undefined                       first referenced
>>> symbol                             in file
>>> NcFile::is_valid() const            /var/tmp//ccHU3abL.o
>>> NcVar::put(float const*, long, long, long, long,
>>> long)/var/tmp//ccHU3abL.o
>>> NcFile::add_att(char const*, char const*)/var/tmp//ccHU3abL.o
>>> NcFile::close()                     /var/tmp//ccHU3abL.o
>>> NcVar::add_att(char const*, float)  /var/tmp//ccHU3abL.o
>>> NcVar::add_att(char const*, long)   /var/tmp//ccHU3abL.o
>>> NcFile::NcFile(char const*, NcFile::FileMode, unsigned int*, unsigned
>>> int, NcFile::FileFormat)/var/tmp//ccHU3abL.o
>>> NcVar::add_att(char const*, char const*)/var/tmp//ccHU3abL.o
>>> ld: fatal: Symbol referencing errors. No output written to pcp_combine
>>> collect2: ld returned 1 exit status
>>> make[3]: *** [pcp_combine] Error 1
>>> make[2]: *** [all] Error 2
>>> make[1]: *** [targets] Error 2
>>> make: *** [all] Error 2
>>>
>>> Since I assumed it might be connected to our version of netcdf I did a
>>> parallel installation of netcdf version 3.6.2 that I downloaded today.
>>> But the result remains the same.
>>>
>>> I assume now that for example is_valid is either not declared within the
>>> netcdf files or it is declared but the file in which it is declared is
>>> not included in the compile.
>>>
>>> Any further suggestions from your side ?
>>>
>>>
>>> In case I would at some point be successful with this installation I
>>> would get you the information on the required steps to get there. Linux
>>> is not an option (at least as of now)
>>>
>>> Thanks,
>>> Helmut Berié
>>>
>>>
>>> John Halley Gotway wrote:
>>>    
>>>> Helmut,
>>>>
>>>> Unfortunately, I don't have an easy fix for you, but I do have a
>>>> couple of suggestions.
>>>>
>>>> MET was developed on Debain Linux, and we've tested it on Debian Linux
>>>> and, to a lesser degree, Macintosh.  However, MET has not been ported
>>>> to Sun Solaris, and I'm not surprised that you're running
>>>> into problems on Solaris.  In the future, we do plan to port MET to
>>>> additional architectures using additional compilers, but currently,
>>>> we're limited by resources.  We don't currently have access to a
>>>> wide variety of machines on which to test.
>>>>
>>>> So first I'd suggest - if you happen to have access to a Linux
>>>> machine, preferably Debian, I'd suggest using it.
>>>>
>>>> If not, you could attempt to port MET to Sun Solaris yourself.  That
>>>> work would be very useful to us, and we could include your
>>>> modifications in future releases of MET.
>>>>
>>>> For this specific problem you're encountering, it appears that your
>>>> system can't find a definition of the "open" function in the include
>>>> files listed at the top of the "vx_wrfdata.cc" file.  I'd
>>>> suggest looking at the man page for "open" on your system to find out
>>>> what header files need to be included to use "open".  But once you get
>>>> past this error, it's likely that you'll run into others.
>>>> I'd be happy to work with you to get through them if you like.
>>>> Unfortunately, there's no way of knowing how easy or difficult the
>>>> port will be in advance.
>>>>
>>>> Your question raises a real issue that we need to discuss internally
>>>> about supporting and testing on additional architectures.  If you do
>>>> decide to attempt porting MET to Sun Solaris, please keep me
>>>> updated.  We'd be very interested in the changes you need to make.
>>>>
>>>> Thanks,
>>>> John Halley Gotway
>>>> johnhg at ucar.edu
>>>>
>>>> Helmut Berie wrote:
>>>>  
>>>>      
>>>>> Hi,
>>>>>
>>>>> We are trying to get the METv0.9 package installed on our Solaris 8
>>>>> workstation tornado. Details of the workstation are given below:
>>>>> SunOS tornado 5.8 Generic_112953-02 sun4u sparc SUNW,Sun-Blade-1000
>>>>>
>>>>>
>>>>> Below is the error message that we receive when running the make
>>>>> script:
>>>>> ...
>>>>> ...
>>>>> cp libvx_pxm.a ../.
>>>>>
>>>>> *** Making vx_render Library ***
>>>>>
>>>>>
>>>>> cp libvx_render.a ../.
>>>>>
>>>>> *** Making vx_util Library ***
>>>>>
>>>>>
>>>>> cp libvx_util.a ../.
>>>>>
>>>>> *** Making vx_wrfdata Library ***
>>>>>
>>>>> /usr/local/bin/g++ vx_wrfdata.cc -g -Wall -Wshadow -static  -c -I..
>>>>> -I/usr/local/pkgs/build/netcdf-3.4/src/cxx
>>>>> vx_wrfdata.cc: In member function `int WrfData::write(const char*,
>>>>> const
>>>>> char*, const char*) const':
>>>>> vx_wrfdata.cc:495: error: `open' undeclared (first use this function)
>>>>> vx_wrfdata.cc:495: error: (Each undeclared identifier is reported only
>>>>> once for each function it appears in.)
>>>>> vx_wrfdata.cc: In member function `int WrfData::read(const char*)':
>>>>> vx_wrfdata.cc:575: error: `open' undeclared (first use this function)
>>>>> ../vx_wrfdata/vx_wrfdata.h: At global scope:
>>>>> ../vx_wrfdata/vx_wrfdata.h:64: warning: 'thresh_type_str' defined but
>>>>> not used
>>>>> ../vx_wrfdata/vx_wrfdata.h:85: warning: 'step_direction_str'
>>>>> defined but
>>>>> not used
>>>>> make[3]: *** [vx_wrfdata.o] Error 1
>>>>> make[2]: *** [vx_wrfdata_all] Error 2
>>>>> make[1]: *** [libs] Error 2
>>>>> make: *** [all] Error 2
>>>>>
>>>>>
>>>>> I would assume that one or more of the prerequisites are not properly
>>>>> met. But at this time I wouldn't know which one.
>>>>>
>>>>> Any suggestions on which part might have to be
>>>>> changed/reinstalled/reconfigured would be highly appreciated.
>>>>>
>>>>>
>>>>> Regards
>>>>> Helmut Berié
>>>>>
>>>>>             
> 


More information about the Met_help mailing list