[Met_help] Problem with running the make script for METv0.9
John Halley Gotway
johnhg at rap.ucar.edu
Mon Oct 8 16:00:28 MDT 2007
Helmut,
I ran across something in which you might be interested. I tried building
MET from scratch today, by going out and downloading all the required
libraries, building them, and then building MET.
However, I found that when I used the latest version of NetCDF (3.6.2),
while MET compiled successfully, I ran into a run time segmentation fault.
When I switched to using the previous version of NetCDF 3.6.1, it
compiled fine and ran without any errors.
So if you're currently using NetCDF 3.6.2, try reverting to 3.6.1, and see
if that works any better.
Version 3.6.1 can be downloaded from:
http://www.unidata.ucar.edu/downloads/netcdf/index.jsp
We'll be sure to address this issue prior to the next release of MET.
Hope this helps.
John Halley Gotway
johnhg at ucar.edu
> Hi John,
>
> I was able to verify using the nm command that symbol is_valid is
> existing in the archive file.
>
> The second part proves to be more tricky as I am not able to get any
> other output out of the pcp_compile step as the one that I already
> forwarded to you. Please let me know if you have additional suggestions
>
> Helmut
>
> 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é
>>>>>>>
>>>>>>>
>>>>>>>
>
>
> --
> --------------------------------------------
> 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
>
More information about the Met_help
mailing list