[Met_help] Problem with running the make script for METv0.9
John Halley Gotway
johnhg at rap.ucar.edu
Thu Oct 4 10:20:21 MDT 2007
Helmut,
Unfortunately, I don't have any more suggestions for you. Based on what you've tested, it sure looks like it should be working.
Would you please send me a copy of the top-level Makefile you're using, and the entire make log? I'd like to look through the whole thing and make sure there isn't something I'm missing.
>From the top level METv0.9 directory do a "make clean" and then "make >& make_met.log" to pipe the output of make to that file "make_met.log".
Thanks,
John
Helmut Berié wrote:
> Hi John,
>
> I got somewhat further with the linker debugging.
>
> When I change the FLAGS section to:
> FLAGS = -g -Wall -Wshadow -static -Xlinker -D -Xlinker files
>
> I am shown file and path information about all files. See help info below:
> debug: files display input file processing (files and libraries)
>
> The interesting part of the output is given below:
> debug: file=../../lib/libvx_util.a(string_fxns.o) [ ET_REL ]
> debug:
> debug: file=../../lib/libvx_util.a [ archive ] (again)
> debug:
> *debug: file=/mnt/geog/gaia/bak41/netcdf-built/lib/libnetcdf_c++.a [
> archive ]
> debug:
> debug: file=/mnt/geog/gaia/bak41/netcdf-built/lib/libnetcdf.a [ archive
> ] *
> debug:
> debug:
> file=/usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../libstdc++.a
> [ archive ]
> debug:
> debug:
> file=/usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../libstdc++.a(globals_io.o)
> [ ET_REL ]
>
> And this sort of indicates that the right libraries are used when trying
> to link the is_valid symbol out of libnetcdf_c++. At least that is my
> understanding of it.
>
> Together with the information I sent you yesterday that means:
> * is_valid is defined in netcdf_c++.
> * netcdf_c++ is utilized when trying to link the reference in
> pcp_combine to the symbol in the library
> * nevertheless the symbol is not found in the library
>
> Please let me know what you think about this.
>
>
> Regards,
> Helmut Berié
>
>
> --------------------------------------------
> Helmut Berié, Computer Systems Administrator
> Department of Geography
> University of Canterbury
> Private Bag 4800, Christchurch, New Zealand
> Email: helmut.berie at canterbury.ac.nz
> Phone: 64-3-364-2987 ext. 7310
> Fax: 64-3-364-2907
>
>
>
> John Halley Gotway wrote:
>> 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