[Met_help] [rt.rap.ucar.edu #65124] History for yellowstone compilation
John Halley Gotway via RT
met_help at ucar.edu
Thu Jan 30 09:58:09 MST 2014
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Trying to compile MET-TC on NCAR's supercomputer yellowstone but getting
compilation errors. They occur before the tropical cyclone section
(TC_UTILS) is compiled.
I managed to hack my way past some initial errors:
avoided the isatty() function by commenting out some lines.
fixed the GSL base directory by taking out the /gsl part of the path
(probably a CISL module problem when module load gsl is loaded)
but now I am stuck. It happens on ensemble_stat:
icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
-Wshadow -static -DBLOCK4
-DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
-I/glade/p/work/ahijevyc/METv4.1/include
-I/glade/apps/opt/netcdf/4.2/intel/default/include
-I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
-I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
-I/glade/apps/el6/include -I/glade/apps/el6/usr/include
-I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
-I/glade/apps/opt/netcdf/4.2/intel/default/include \
-L/glade/p/work/ahijevyc/METv4.1/lib
-L/glade/apps/opt/netcdf/4.2/intel/default/lib
-L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
-Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
-Wl,-rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
-Wl,-rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
-L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
-Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-rpath,/glade/apps/el6/usr/lib64
-L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
-lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
-Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
-L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4 -lnetcdff
-lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib \
-lvx_stat_out \
-lvx_statistics \
-lvx_shapedata \
-lvx_gsl_prob \
-lvx_analysis_util \
-lvx_data2d_factory \
-lvx_data2d_nc_met \
-lvx_data2d_grib \
-lvx_data2d_nc_pinterp \
-lvx_data2d_nccf \
-lvx_data2d \
-lvx_nc_util \
-lvx_grid \
-lvx_config \
-lvx_cal \
-lvx_util \
-lvx_math \
-lvx_color \
-lvx_log \
-lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o): In
function `H5PL_load':
H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-ochttp.o):
In function `ocfetchhttpcode':
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
undefined reference to `curl_easy_getinfo'
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-ochttp.o):
In function `ocfetchurl_file':
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
undefined reference to `curl_easy_perform'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
undefined reference to `curl_easy_getinfo'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
undefined reference to `curl_easy_strerror'
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-ochttp.o):
In function `ocfetchlastmodified':
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:265:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:270:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:271:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:272:
undefined reference to `curl_easy_setopt'
/glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:273:
undefined reference to `curl_easy_setopt'
...more errors follow
It seems to be related to the curl library and suggests netcdf needs it,
but I want to avoid compiling netcdf and just use the supercomputer
version.
I found this helpful email reference to compiled MET on yellowstone, but
I couldn't find any tc_utils in
/glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the email, it
seemed the compilation was not working recently.
http://mailman.ucar.edu/pipermail/met_help/2014-January/002071.html
Dave
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: John Halley Gotway
Time: Tue Jan 28 11:08:03 2014
Hi Dave,
I'm looking into and will let you know when I've made progress. I'd
seen that "isatty()" problem, but hadn't had a chance to address it
yet.
Thanks,
John
On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>
> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
> Transaction: Ticket created by ahijevyc
> Queue: met_help
> Subject: yellowstone compilation
> Owner: Nobody
> Requestors: ahijevyc at ucar.edu
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>
>
> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
> compilation errors. They occur before the tropical cyclone section
> (TC_UTILS) is compiled.
>
> I managed to hack my way past some initial errors:
> avoided the isatty() function by commenting out some lines.
> fixed the GSL base directory by taking out the /gsl part of the
path
> (probably a CISL module problem when module load gsl is loaded)
>
> but now I am stuck. It happens on ensemble_stat:
>
>
> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
> -Wshadow -static -DBLOCK4
> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
> -I/glade/p/work/ahijevyc/METv4.1/include
> -I/glade/apps/opt/netcdf/4.2/intel/default/include
> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
> -L/glade/p/work/ahijevyc/METv4.1/lib
> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib \
> -lvx_stat_out \
> -lvx_statistics \
> -lvx_shapedata \
> -lvx_gsl_prob \
> -lvx_analysis_util \
> -lvx_data2d_factory \
> -lvx_data2d_nc_met \
> -lvx_data2d_grib \
> -lvx_data2d_nc_pinterp \
> -lvx_data2d_nccf \
> -lvx_data2d \
> -lvx_nc_util \
> -lvx_grid \
> -lvx_config \
> -lvx_cal \
> -lvx_util \
> -lvx_math \
> -lvx_color \
> -lvx_log \
> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>
> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o): In
> function `H5PL_load':
> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically linked
> applications requires at runtime the shared libraries from the glibc
> version used for linking
> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
> In function `ocfetchhttpcode':
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
> undefined reference to `curl_easy_getinfo'
> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
> In function `ocfetchurl_file':
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
> undefined reference to `curl_easy_perform'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
> undefined reference to `curl_easy_getinfo'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
> undefined reference to `curl_easy_strerror'
> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
> In function `ocfetchlastmodified':
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:265:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:270:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:271:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:272:
> undefined reference to `curl_easy_setopt'
> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:273:
> undefined reference to `curl_easy_setopt'
> ...more errors follow
>
>
> It seems to be related to the curl library and suggests netcdf needs
it,
> but I want to avoid compiling netcdf and just use the supercomputer
> version.
>
> I found this helpful email reference to compiled MET on yellowstone,
but
> I couldn't find any tc_utils in
> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
> seemed the compilation was not working recently.
> http://mailman.ucar.edu/pipermail/met_help/2014-January/002071.html
>
> Dave
>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Tue Jan 28 11:11:03 2014
OKay - thanks!
On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
> Hi Dave,
>
> I'm looking into and will let you know when I've made progress. I'd
seen that "isatty()" problem, but hadn't had a chance to address it
yet.
>
> Thanks,
> John
>
>
> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>> Transaction: Ticket created by ahijevyc
>> Queue: met_help
>> Subject: yellowstone compilation
>> Owner: Nobody
>> Requestors: ahijevyc at ucar.edu
>> Status: new
>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>
>>
>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>> compilation errors. They occur before the tropical cyclone section
>> (TC_UTILS) is compiled.
>>
>> I managed to hack my way past some initial errors:
>> avoided the isatty() function by commenting out some lines.
>> fixed the GSL base directory by taking out the /gsl part of the
path
>> (probably a CISL module problem when module load gsl is loaded)
>>
>> but now I am stuck. It happens on ensemble_stat:
>>
>>
>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
>> -Wshadow -static -DBLOCK4
>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>> -I/glade/p/work/ahijevyc/METv4.1/include
>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>> -L/glade/p/work/ahijevyc/METv4.1/lib
>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib \
>> -lvx_stat_out \
>> -lvx_statistics \
>> -lvx_shapedata \
>> -lvx_gsl_prob \
>> -lvx_analysis_util \
>> -lvx_data2d_factory \
>> -lvx_data2d_nc_met \
>> -lvx_data2d_grib \
>> -lvx_data2d_nc_pinterp \
>> -lvx_data2d_nccf \
>> -lvx_data2d \
>> -lvx_nc_util \
>> -lvx_grid \
>> -lvx_config \
>> -lvx_cal \
>> -lvx_util \
>> -lvx_math \
>> -lvx_color \
>> -lvx_log \
>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>
>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o): In
>> function `H5PL_load':
>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically linked
>> applications requires at runtime the shared libraries from the
glibc
>> version used for linking
>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>> In function `ocfetchhttpcode':
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
>> undefined reference to `curl_easy_getinfo'
>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>> In function `ocfetchurl_file':
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
>> undefined reference to `curl_easy_perform'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
>> undefined reference to `curl_easy_getinfo'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
>> undefined reference to `curl_easy_strerror'
>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>> In function `ocfetchlastmodified':
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:265:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:270:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:271:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:272:
>> undefined reference to `curl_easy_setopt'
>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:273:
>> undefined reference to `curl_easy_setopt'
>> ...more errors follow
>>
>>
>> It seems to be related to the curl library and suggests netcdf
needs it,
>> but I want to avoid compiling netcdf and just use the supercomputer
>> version.
>>
>> I found this helpful email reference to compiled MET on
yellowstone, but
>> I couldn't find any tc_utils in
>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>> seemed the compilation was not working recently.
>> http://mailman.ucar.edu/pipermail/met_help/2014-January/002071.html
>>
>> Dave
>>
>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: John Halley Gotway
Time: Tue Jan 28 14:21:25 2014
Dave,
OK, we should be all set. For some reason the current version of the
intel compiler doesn't define the isatty() function. Randy and I
talked about it and decided to redefine that function ourselves
in the MET code. I just finished compiling MET on yellowstone in:
/glade/p/ral/jnt/MET/MET_releases/METv4.1
In there, you'll find an updated set of patches that include these
small changes: METv4.1_patches_20140128.tar.gz
Just copy that into you top-level METv4.1 directory and unpack it.
I'll also post that patches file to the known issues page:
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
Regarding NetCDF, MET's looking for a 3.x version instead of a 4.x.
It's NetCDF that's looking for that curl stuff. You can just point
NetCDF to this version:
/glade/p/ral/jnt/tools/netcdf-3.6.3
Please give that a shot and let me know if you have any more problems
compiling in yellowstone. We obviously want MET to run smoothly
there!
Thanks,
John
On 01/28/2014 11:11 AM, David Ahijevych via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>
> OKay - thanks!
> On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
>> Hi Dave,
>>
>> I'm looking into and will let you know when I've made progress.
I'd seen that "isatty()" problem, but hadn't had a chance to address
it yet.
>>
>> Thanks,
>> John
>>
>>
>> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>>> Transaction: Ticket created by ahijevyc
>>> Queue: met_help
>>> Subject: yellowstone compilation
>>> Owner: Nobody
>>> Requestors: ahijevyc at ucar.edu
>>> Status: new
>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>
>>>
>>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>>> compilation errors. They occur before the tropical cyclone section
>>> (TC_UTILS) is compiled.
>>>
>>> I managed to hack my way past some initial errors:
>>> avoided the isatty() function by commenting out some lines.
>>> fixed the GSL base directory by taking out the /gsl part of
the path
>>> (probably a CISL module problem when module load gsl is loaded)
>>>
>>> but now I am stuck. It happens on ensemble_stat:
>>>
>>>
>>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
>>> -Wshadow -static -DBLOCK4
>>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>>> -I/glade/p/work/ahijevyc/METv4.1/include
>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>>> -L/glade/p/work/ahijevyc/METv4.1/lib
>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib
\
>>> -lvx_stat_out \
>>> -lvx_statistics \
>>> -lvx_shapedata \
>>> -lvx_gsl_prob \
>>> -lvx_analysis_util \
>>> -lvx_data2d_factory \
>>> -lvx_data2d_nc_met \
>>> -lvx_data2d_grib \
>>> -lvx_data2d_nc_pinterp \
>>> -lvx_data2d_nccf \
>>> -lvx_data2d \
>>> -lvx_nc_util \
>>> -lvx_grid \
>>> -lvx_config \
>>> -lvx_cal \
>>> -lvx_util \
>>> -lvx_math \
>>> -lvx_color \
>>> -lvx_log \
>>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>>
>>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o): In
>>> function `H5PL_load':
>>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically linked
>>> applications requires at runtime the shared libraries from the
glibc
>>> version used for linking
>>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>> In function `ocfetchhttpcode':
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
>>> undefined reference to `curl_easy_getinfo'
>>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>> In function `ocfetchurl_file':
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
>>> undefined reference to `curl_easy_perform'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
>>> undefined reference to `curl_easy_getinfo'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
>>> undefined reference to `curl_easy_strerror'
>>> /glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>> In function `ocfetchlastmodified':
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:265:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:270:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:271:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:272:
>>> undefined reference to `curl_easy_setopt'
>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:273:
>>> undefined reference to `curl_easy_setopt'
>>> ...more errors follow
>>>
>>>
>>> It seems to be related to the curl library and suggests netcdf
needs it,
>>> but I want to avoid compiling netcdf and just use the
supercomputer
>>> version.
>>>
>>> I found this helpful email reference to compiled MET on
yellowstone, but
>>> I couldn't find any tc_utils in
>>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>>> seemed the compilation was not working recently.
>>> http://mailman.ucar.edu/pipermail/met_help/2014-
January/002071.html
>>>
>>> Dave
>>>
>>>
>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Wed Jan 29 10:02:51 2014
Thanks John _ I'll try it now. FYI, you introduced a typo in the MET
known issue page right below the section you added. (Right below "And
then recompile MET" it says "h3>")
dave
On 1/28/14 2:21 PM, John Halley Gotway via RT wrote:
> Dave,
>
> OK, we should be all set. For some reason the current version of
the intel compiler doesn't define the isatty() function. Randy and I
talked about it and decided to redefine that function ourselves
> in the MET code. I just finished compiling MET on yellowstone in:
> /glade/p/ral/jnt/MET/MET_releases/METv4.1
>
> In there, you'll find an updated set of patches that include these
small changes: METv4.1_patches_20140128.tar.gz
> Just copy that into you top-level METv4.1 directory and unpack it.
>
> I'll also post that patches file to the known issues page:
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>
> Regarding NetCDF, MET's looking for a 3.x version instead of a 4.x.
It's NetCDF that's looking for that curl stuff. You can just point
NetCDF to this version:
> /glade/p/ral/jnt/tools/netcdf-3.6.3
>
> Please give that a shot and let me know if you have any more
problems compiling in yellowstone. We obviously want MET to run
smoothly there!
>
> Thanks,
> John
>
>
> On 01/28/2014 11:11 AM, David Ahijevych via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>
>> OKay - thanks!
>> On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
>>> Hi Dave,
>>>
>>> I'm looking into and will let you know when I've made progress.
I'd seen that "isatty()" problem, but hadn't had a chance to address
it yet.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>>>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>>>> Transaction: Ticket created by ahijevyc
>>>> Queue: met_help
>>>> Subject: yellowstone compilation
>>>> Owner: Nobody
>>>> Requestors: ahijevyc at ucar.edu
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>>
>>>>
>>>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>>>> compilation errors. They occur before the tropical cyclone
section
>>>> (TC_UTILS) is compiled.
>>>>
>>>> I managed to hack my way past some initial errors:
>>>> avoided the isatty() function by commenting out some lines.
>>>> fixed the GSL base directory by taking out the /gsl part of
the path
>>>> (probably a CISL module problem when module load gsl is loaded)
>>>>
>>>> but now I am stuck. It happens on ensemble_stat:
>>>>
>>>>
>>>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
>>>> -Wshadow -static -DBLOCK4
>>>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>>>> -I/glade/p/work/ahijevyc/METv4.1/include
>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>>>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>>>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>>>> -L/glade/p/work/ahijevyc/METv4.1/lib
>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>>>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>>>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>>>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>>>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>>>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>>>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>>>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>>>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib
\
>>>> -lvx_stat_out \
>>>> -lvx_statistics \
>>>> -lvx_shapedata \
>>>> -lvx_gsl_prob \
>>>> -lvx_analysis_util \
>>>> -lvx_data2d_factory \
>>>> -lvx_data2d_nc_met \
>>>> -lvx_data2d_grib \
>>>> -lvx_data2d_nc_pinterp \
>>>> -lvx_data2d_nccf \
>>>> -lvx_data2d \
>>>> -lvx_nc_util \
>>>> -lvx_grid \
>>>> -lvx_config \
>>>> -lvx_cal \
>>>> -lvx_util \
>>>> -lvx_math \
>>>> -lvx_color \
>>>> -lvx_log \
>>>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>>>
>>>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o):
In
>>>> function `H5PL_load':
>>>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically
linked
>>>> applications requires at runtime the shared libraries from the
glibc
>>>> version used for linking
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchhttpcode':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
>>>> undefined reference to `curl_easy_getinfo'
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchurl_file':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
>>>> undefined reference to `curl_easy_perform'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
>>>> undefined reference to `curl_easy_getinfo'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
>>>> undefined reference to `curl_easy_strerror'
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchlastmodified':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:265:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:270:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:271:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:272:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:273:
>>>> undefined reference to `curl_easy_setopt'
>>>> ...more errors follow
>>>>
>>>>
>>>> It seems to be related to the curl library and suggests netcdf
needs it,
>>>> but I want to avoid compiling netcdf and just use the
supercomputer
>>>> version.
>>>>
>>>> I found this helpful email reference to compiled MET on
yellowstone, but
>>>> I couldn't find any tc_utils in
>>>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>>>> seemed the compilation was not working recently.
>>>> http://mailman.ucar.edu/pipermail/met_help/2014-
January/002071.html
>>>>
>>>> Dave
>>>>
>>>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: David Ahijevych
Time: Wed Jan 29 10:18:46 2014
Yes! Got it to compile after setting NETCDF_BASE to
/glade/p/ral/jnt/tools/netcdf-3.6.3
Thanks!
dave
On 1/28/14 2:21 PM, John Halley Gotway via RT wrote:
> Dave,
>
> OK, we should be all set. For some reason the current version of
the intel compiler doesn't define the isatty() function. Randy and I
talked about it and decided to redefine that function ourselves
> in the MET code. I just finished compiling MET on yellowstone in:
> /glade/p/ral/jnt/MET/MET_releases/METv4.1
>
> In there, you'll find an updated set of patches that include these
small changes: METv4.1_patches_20140128.tar.gz
> Just copy that into you top-level METv4.1 directory and unpack it.
>
> I'll also post that patches file to the known issues page:
>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>
> Regarding NetCDF, MET's looking for a 3.x version instead of a 4.x.
It's NetCDF that's looking for that curl stuff. You can just point
NetCDF to this version:
> /glade/p/ral/jnt/tools/netcdf-3.6.3
>
> Please give that a shot and let me know if you have any more
problems compiling in yellowstone. We obviously want MET to run
smoothly there!
>
> Thanks,
> John
>
>
> On 01/28/2014 11:11 AM, David Ahijevych via RT wrote:
>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>
>> OKay - thanks!
>> On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
>>> Hi Dave,
>>>
>>> I'm looking into and will let you know when I've made progress.
I'd seen that "isatty()" problem, but hadn't had a chance to address
it yet.
>>>
>>> Thanks,
>>> John
>>>
>>>
>>> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>>>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>>>> Transaction: Ticket created by ahijevyc
>>>> Queue: met_help
>>>> Subject: yellowstone compilation
>>>> Owner: Nobody
>>>> Requestors: ahijevyc at ucar.edu
>>>> Status: new
>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>>
>>>>
>>>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>>>> compilation errors. They occur before the tropical cyclone
section
>>>> (TC_UTILS) is compiled.
>>>>
>>>> I managed to hack my way past some initial errors:
>>>> avoided the isatty() function by commenting out some lines.
>>>> fixed the GSL base directory by taking out the /gsl part of
the path
>>>> (probably a CISL module problem when module load gsl is loaded)
>>>>
>>>> but now I am stuck. It happens on ensemble_stat:
>>>>
>>>>
>>>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o \
>>>> -Wshadow -static -DBLOCK4
>>>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>>>> -I/glade/p/work/ahijevyc/METv4.1/include
>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>>>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>>>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>>>> -L/glade/p/work/ahijevyc/METv4.1/lib
>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>>>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>>>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>>>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>>>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>>>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>>>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>>>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>>>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib
\
>>>> -lvx_stat_out \
>>>> -lvx_statistics \
>>>> -lvx_shapedata \
>>>> -lvx_gsl_prob \
>>>> -lvx_analysis_util \
>>>> -lvx_data2d_factory \
>>>> -lvx_data2d_nc_met \
>>>> -lvx_data2d_grib \
>>>> -lvx_data2d_nc_pinterp \
>>>> -lvx_data2d_nccf \
>>>> -lvx_data2d \
>>>> -lvx_nc_util \
>>>> -lvx_grid \
>>>> -lvx_config \
>>>> -lvx_cal \
>>>> -lvx_util \
>>>> -lvx_math \
>>>> -lvx_color \
>>>> -lvx_log \
>>>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>>>
>>>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o):
In
>>>> function `H5PL_load':
>>>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically
linked
>>>> applications requires at runtime the shared libraries from the
glibc
>>>> version used for linking
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchhttpcode':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:29:
>>>> undefined reference to `curl_easy_getinfo'
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchurl_file':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:43:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:48:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:53:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:58:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:64:
>>>> undefined reference to `curl_easy_perform'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:77:
>>>> undefined reference to `curl_easy_getinfo'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-4.2.1.1/oc/ochttp.c:83:
>>>> undefined reference to `curl_easy_strerror'
>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>> In function `ocfetchlastmodified':
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:265:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:270:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:271:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:272:
>>>> undefined reference to `curl_easy_setopt'
>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:273:
>>>> undefined reference to `curl_easy_setopt'
>>>> ...more errors follow
>>>>
>>>>
>>>> It seems to be related to the curl library and suggests netcdf
needs it,
>>>> but I want to avoid compiling netcdf and just use the
supercomputer
>>>> version.
>>>>
>>>> I found this helpful email reference to compiled MET on
yellowstone, but
>>>> I couldn't find any tc_utils in
>>>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>>>> seemed the compilation was not working recently.
>>>> http://mailman.ucar.edu/pipermail/met_help/2014-
January/002071.html
>>>>
>>>> Dave
>>>>
>>>>
------------------------------------------------
Subject: Re: [rt.rap.ucar.edu #65124] yellowstone compilation
From: John Halley Gotway
Time: Thu Jan 30 09:57:58 2014
Dave,
Thanks for the heads up about the typo. That's what I get for editing
the html files directly.
Glad that did the trick. If you're using the MET-TC tools for the
first time...
- Here's the location of the user's guide: METv4.1/doc/MET-
TC_Users_Guide.pdf
- Here's a MET-TC exercise from the tutorial this year:
http://www.dtcenter.org/met/users/support/OnLinePractical/OnLinePractical_114/met_tc/index.php
- Kathryn Newman, Christopher Williams, and I have a lot of experience
configuring/running the tools. And we'd all be happy to answer any
questions that come up.
I'll go ahead and resolve this ticket.
Thanks,
John
On 01/29/2014 10:18 AM, David Ahijevych via RT wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>
> Yes! Got it to compile after setting NETCDF_BASE to
>
> /glade/p/ral/jnt/tools/netcdf-3.6.3
>
> Thanks!
>
> dave
>
>
>
> On 1/28/14 2:21 PM, John Halley Gotway via RT wrote:
>> Dave,
>>
>> OK, we should be all set. For some reason the current version of
the intel compiler doesn't define the isatty() function. Randy and I
talked about it and decided to redefine that function ourselves
>> in the MET code. I just finished compiling MET on yellowstone in:
>> /glade/p/ral/jnt/MET/MET_releases/METv4.1
>>
>> In there, you'll find an updated set of patches that include these
small changes: METv4.1_patches_20140128.tar.gz
>> Just copy that into you top-level METv4.1 directory and unpack it.
>>
>> I'll also post that patches file to the known issues page:
>>
http://www.dtcenter.org/met/users/support/known_issues/METv4.1/index.php
>>
>> Regarding NetCDF, MET's looking for a 3.x version instead of a 4.x.
It's NetCDF that's looking for that curl stuff. You can just point
NetCDF to this version:
>> /glade/p/ral/jnt/tools/netcdf-3.6.3
>>
>> Please give that a shot and let me know if you have any more
problems compiling in yellowstone. We obviously want MET to run
smoothly there!
>>
>> Thanks,
>> John
>>
>>
>> On 01/28/2014 11:11 AM, David Ahijevych via RT wrote:
>>> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>
>>> OKay - thanks!
>>> On 1/28/14 11:08 AM, John Halley Gotway via RT wrote:
>>>> Hi Dave,
>>>>
>>>> I'm looking into and will let you know when I've made progress.
I'd seen that "isatty()" problem, but hadn't had a chance to address
it yet.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>>
>>>> On 01/28/2014 10:28 AM, David Ahijevych via RT wrote:
>>>>> Tue Jan 28 10:28:41 2014: Request 65124 was acted upon.
>>>>> Transaction: Ticket created by ahijevyc
>>>>> Queue: met_help
>>>>> Subject: yellowstone compilation
>>>>> Owner: Nobody
>>>>> Requestors: ahijevyc at ucar.edu
>>>>> Status: new
>>>>> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=65124 >
>>>>>
>>>>>
>>>>> Trying to compile MET-TC on NCAR's supercomputer yellowstone but
getting
>>>>> compilation errors. They occur before the tropical cyclone
section
>>>>> (TC_UTILS) is compiled.
>>>>>
>>>>> I managed to hack my way past some initial errors:
>>>>> avoided the isatty() function by commenting out some
lines.
>>>>> fixed the GSL base directory by taking out the /gsl part
of the path
>>>>> (probably a CISL module problem when module load gsl is loaded)
>>>>>
>>>>> but now I am stuck. It happens on ensemble_stat:
>>>>>
>>>>>
>>>>> icc -o ensemble_stat ensemble_stat.cc ensemble_stat_conf_info.o
\
>>>>> -Wshadow -static -DBLOCK4
>>>>> -DMET_BASE=\"/glade/p/work/ahijevyc/METv4.1\" \
>>>>> -I/glade/p/work/ahijevyc/METv4.1/include
>>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include
>>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include
>>>>> -I/glade/apps/opt/gsl/1.15/gnu/4.7.2/include/gsl
>>>>> -I/glade/apps/el6/include -I/glade/apps/el6/usr/include
>>>>> -I/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/include
>>>>> -I/glade/apps/opt/netcdf/4.2/intel/default/include \
>>>>> -L/glade/p/work/ahijevyc/METv4.1/lib
>>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib
>>>>> -L/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib -lgslcblas -lgsl
>>>>> -Wl,-rpath,/glade/apps/opt/gsl/1.15/gnu/4.7.2/lib
>>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/intel64
>>>>> -Wl,-
rpath,/ncar/opt/intel/12.1.0.233/composer_xe_2011_sp1.11.339/compiler/lib/ia32
>>>>> -L/glade/apps/el6/usr/lib -L/glade/apps/el6/usr/lib64
>>>>> -Wl,-rpath,/glade/apps/el6/usr/lib -Wl,-
rpath,/glade/apps/el6/usr/lib64
>>>>> -L/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib -lhdf5 -lhdf5_hl
>>>>> -lhdf5_fortran -lhdf5hl_fortran -lhdf5_cpp -lhdf5_hl_cpp
>>>>> -Wl,-rpath,/glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib
>>>>> -L/glade/apps/opt/netcdf/4.2/intel/default/lib -lnetcdf_c++4
-lnetcdff
>>>>> -lnetcdf -Wl,-rpath,/glade/apps/opt/netcdf/4.2/intel/default/lib
\
>>>>> -lvx_stat_out \
>>>>> -lvx_statistics \
>>>>> -lvx_shapedata \
>>>>> -lvx_gsl_prob \
>>>>> -lvx_analysis_util \
>>>>> -lvx_data2d_factory \
>>>>> -lvx_data2d_nc_met \
>>>>> -lvx_data2d_grib \
>>>>> -lvx_data2d_nc_pinterp \
>>>>> -lvx_data2d_nccf \
>>>>> -lvx_data2d \
>>>>> -lvx_nc_util \
>>>>> -lvx_grid \
>>>>> -lvx_config \
>>>>> -lvx_cal \
>>>>> -lvx_util \
>>>>> -lvx_math \
>>>>> -lvx_color \
>>>>> -lvx_log \
>>>>> -lm -lnetcdf_c++ -lnetcdf -lgsl -lgslcblas \
>>>>>
>>>>> /glade/apps/opt/hdf5/1.8.11/intel/12.1.5/lib/libhdf5.a(H5PL.o):
In
>>>>> function `H5PL_load':
>>>>> H5PL.c:(.text+0x38b): warning: Using 'dlopen' in statically
linked
>>>>> applications requires at runtime the shared libraries from the
glibc
>>>>> version used for linking
>>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>>> In function `ocfetchhttpcode':
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:29:
>>>>> undefined reference to `curl_easy_getinfo'
>>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>>> In function `ocfetchurl_file':
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:43:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:48:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:53:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:58:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:64:
>>>>> undefined reference to `curl_easy_perform'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:77:
>>>>> undefined reference to `curl_easy_getinfo'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:83:
>>>>> undefined reference to `curl_easy_strerror'
>>>>>
/glade/apps/opt/netcdf/4.2/intel/default/lib/libnetcdf.a(liboc_la-
ochttp.o):
>>>>> In function `ocfetchlastmodified':
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:265:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:270:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:271:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:272:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> /glade/u/apps/opt/netcdf/4.2/intel/netcdf-
4.2.1.1/oc/ochttp.c:273:
>>>>> undefined reference to `curl_easy_setopt'
>>>>> ...more errors follow
>>>>>
>>>>>
>>>>> It seems to be related to the curl library and suggests netcdf
needs it,
>>>>> but I want to avoid compiling netcdf and just use the
supercomputer
>>>>> version.
>>>>>
>>>>> I found this helpful email reference to compiled MET on
yellowstone, but
>>>>> I couldn't find any tc_utils in
>>>>> /glade/p/ral/jnt/MMET/CODE/MET/v4.1/METv4.1/bin. And from the
email, it
>>>>> seemed the compilation was not working recently.
>>>>> http://mailman.ucar.edu/pipermail/met_help/2014-
January/002071.html
>>>>>
>>>>> Dave
>>>>>
>>>>>
>
------------------------------------------------
More information about the Met_help
mailing list