[Met_help] [rt.rap.ucar.edu #96693] History for Configure error -- upgrade to MET 9.1 from 8.1.2
Julie Prestopnik via RT
met_help at ucar.edu
Mon Sep 21 15:53:16 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hi all,
I'm finally getting around to installing 9.1; I currently have 8.1.1 running properly on the same machine.
I've run into a configuration error regarding gcc. I feel like I've encountered this error somewhere before...perhaps with NETCDF, but I'm not sure, and I can't find anything in my notes as to how I worked around it.
Anyway, I'm running into an issue with the -V command for gcc:
g++: error: unrecognized command line option '-V'
g++: fatal error: no input files
compilation terminated.
configure:5024: $? = 4
configure:5013: g++ -qversion >&5
g++: error: unrecognized command line option '-qversion'
g++: fatal error: no input files
compilation terminated.
I've included the full config.log for reference.
Also note I have an issue with my python library file-I'll work on straightening that out in the meantime.
Any guidance you can provide, I'd appreciate!
Thanks,
-Tom
[https://firstenergycorp.com/content/dam/opcologos/emailsig/FE-logo.png]
Thomas Workoff
Sr Scientist
office: 330-436-1475 (850-1475)
tworkoff at firstenergycorp.com
341 White Pond Drive, Akron, OH 44320 | mailstop: A-WAC-C1 / AK-West Akron Campus
------------------------------------------------------------------------------
The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Julie Prestopnik
Time: Mon Sep 14 09:23:24 2020
Hi Tom.
I see that you are having trouble installing met-9.1. Thank you for
attaching your config.log file. It looks like this is the problem:
/usr/bin/ld: cannot find -lpython-config.py
>
> collect2: error: ld returned 1 exit status
>
Can you please run the following and let me know what the output is?
python3-config --cflags
> python3-config --ldflags
Once I see those, I should be able to make sure that the values for
MET_PYTHON_CC and MET_PYTHON_LD are set correctly.
Thanks!
Julie
On Mon, Sep 14, 2020 at 7:31 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> Mon Sep 14 07:31:50 2020: Request 96693 was acted upon.
> Transaction: Ticket created by tworkoff at firstenergycorp.com
> Queue: met_help
> Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
> Owner: Nobody
> Requestors: tworkoff at firstenergycorp.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
>
> Hi all,
>
> I'm finally getting around to installing 9.1; I currently have 8.1.1
> running properly on the same machine.
>
> I've run into a configuration error regarding gcc. I feel like I've
> encountered this error somewhere before...perhaps with NETCDF, but
I'm not
> sure, and I can't find anything in my notes as to how I worked
around it.
>
> Anyway, I'm running into an issue with the -V command for gcc:
>
> g++: error: unrecognized command line option '-V'
> g++: fatal error: no input files
> compilation terminated.
> configure:5024: $? = 4
> configure:5013: g++ -qversion >&5
> g++: error: unrecognized command line option '-qversion'
> g++: fatal error: no input files
> compilation terminated.
>
> I've included the full config.log for reference.
>
> Also note I have an issue with my python library file-I'll work on
> straightening that out in the meantime.
>
> Any guidance you can provide, I'd appreciate!
>
> Thanks,
> -Tom
>
>
>
> [https://firstenergycorp.com/content/dam/opcologos/emailsig/FE-
logo.png]
>
> Thomas Workoff
> Sr Scientist
> office: 330-436-1475 (850-1475)
> tworkoff at firstenergycorp.com
> 341 White Pond Drive, Akron, OH 44320 | mailstop: A-WAC-C1 / AK-West
Akron
> Campus
>
>
>
------------------------------------------------------------------------------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
hereby
> notified that you have received this document in error and that any
review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately, and delete the original message.
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Workoff, Thomas E
Time: Mon Sep 14 10:02:57 2020
Good Morning Julie,
Thanks for the quick response.
I have a feeling the python arrangement on this system could be where
the problem is. Given it's an older redhat build (that part I can't
get around, per IT), python2.7 is the one that's linked/seen by the
system. We have python3.7 installed, but a simple command for the
python3 config doesn't work:
----------------------------------
python3-config -ldflags
python3-config: Command not found.
python3.7-config -ldflags
python3.7-config: Command not found.
-------------------------------------------------
Currently, these are how my python environmental variables are defined
in the .cshrc:
setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
setenv MET_PYTHON_LD '-L/usr/local/lib/python3.7/config-3.7m-x86_64-
linux-gnu -lpython-config.py'
Perhaps I’m routing that incorrectly?
For reference, here is the listing of the
/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu Directory;
-rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
-rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
-rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
-rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
-rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
-rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
-rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
-rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
-rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
-rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
For the record, Python.h does exist in /usr/local/include/python3.7m
I realized I had a typo in the filepath for MET_PYTHON_LD the first
time, but fixing that hasn’t helped the problem. The new log file is
attached.
I a problem linking python3.7 with the 8.1.2 installation….but let it
compile with 2.7 since I wasn’t using python for anything taxing at
the time. But given we’ll be leaning on METplus heavily going
forward, I wanted to figure this out with the installation of 9.1.
Thanks for looking this over!
-----Original Message-----
From: Julie Prestopnik via RT <met_help at ucar.edu>
Sent: Monday, September 14, 2020 11:23 AM
To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
Subject: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error --
upgrade to MET 9.1 from 8.1.2
Hi Tom.
I see that you are having trouble installing met-9.1. Thank you for
attaching your config.log file. It looks like this is the problem:
/usr/bin/ld: cannot find -lpython-config.py
>
> collect2: error: ld returned 1 exit status
>
Can you please run the following and let me know what the output is?
python3-config --cflags
> python3-config --ldflags
Once I see those, I should be able to make sure that the values for
MET_PYTHON_CC and MET_PYTHON_LD are set correctly.
Thanks!
Julie
On Mon, Sep 14, 2020 at 7:31 AM Workoff, Thomas E via RT
<mailto:met_help at ucar.edu>
wrote:
>
> Mon Sep 14 07:31:50 2020: Request 96693 was acted upon.
> Transaction: Ticket created by mailto:tworkoff at firstenergycorp.com
> Queue: met_help
> Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
> Owner: Nobody
> Requestors: mailto:tworkoff at firstenergycorp.com
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693
> >
>
>
> Hi all,
>
> I'm finally getting around to installing 9.1; I currently have 8.1.1
> running properly on the same machine.
>
> I've run into a configuration error regarding gcc. I feel like I've
> encountered this error somewhere before...perhaps with NETCDF, but
I'm
> not sure, and I can't find anything in my notes as to how I worked
around it.
>
> Anyway, I'm running into an issue with the -V command for gcc:
>
> g++: error: unrecognized command line option '-V'
> g++: fatal error: no input files
> compilation terminated.
> configure:5024: $? = 4
> configure:5013: g++ -qversion >&5
> g++: error: unrecognized command line option '-qversion'
> g++: fatal error: no input files
> compilation terminated.
>
> I've included the full config.log for reference.
>
> Also note I have an issue with my python library file-I'll work on
> straightening that out in the meantime.
>
> Any guidance you can provide, I'd appreciate!
>
> Thanks,
> -Tom
>
>
>
> [https://firstenergycorp.com/content/dam/opcologos/emailsig/FE-
logo.pn
> g]
>
> Thomas Workoff
> Sr Scientist
> office: 330-436-1475 (850-1475)
> mailto:tworkoff at firstenergycorp.com
> 341 White Pond Drive, Akron, OH 44320 | mailstop: A-WAC-C1 / AK-West
> Akron Campus
>
>
>
----------------------------------------------------------------------
> --------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
> hereby notified that you have received this document in error and
that
> any review, dissemination, distribution, or copying of this message
is
> strictly prohibited. If you have received this communication in
error,
> please notify us immediately, and delete the original message.
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research Research Applications
Laboratory
Phone: 303.497.8399
Email: mailto:jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to reply to this email outside of your normal working hours.
------------------------------------------------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Julie Prestopnik
Time: Mon Sep 14 10:38:54 2020
Hi Tom.
Thank you for the additional information and for your new config.log
file.
It looks like Python is still having trouble:
/usr/bin/ld: cannot find -l/usr/local/include/python3.7m
>
> collect2: error: ld returned 1 exit status
>
I have a feeling the python arrangement on this system could be where
the
> problem is.
>
That could very well be. Let's see what we can figure out and try to
get
it set up correctly, assuming the Python arrangement is ok on your
system.
Do you know where the python3 executable lives? Perhaps
in /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping the
"python3-config" executable will be in the same directory and that you
received "python3-config: Command not found." because it was just not
in
your path. Being able to run "python3-config --cflags" and "python3-
config
--ldflags" will help us know what we should set MET_PYTHON_CC and
MET_PYTHON_LD flags to.
For the record, Python.h does exist in /usr/local/include/python3.7m
>
Hrm. If you run "find /usr/local/ -name Python.h", can you find it?
Currently, these are how my python environmental variables are defined
in
> the .cshrc:
setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> setenv MET_PYTHON_LD
> '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu -lpython-
config.py'
> Perhaps I’m routing that incorrectly?
Typically we wouldn't have "-lpython-config.py", but rather
"-lpython3.7m". There would also typically be other libraries to link
with
as well and sometimes another path as well. Here are some examples
from
two different machines:
setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\ -lcrypt\
> -lpthread\ -ldl\ -lutil\ -lm
and
export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
-lpython3.6m\
> -lpthread\ -ldl\ -lutil\ -lrt\ -lm
But given we’ll be leaning on METplus heavily going forward, I wanted
to
> figure this out with the installation of 9.1.
We're so glad to hear that you will be using METplus heavily. I hope
we
can get the Python embedding functionality working for you. It's such
a
great tool to have. We're happy to help with whatever you need with
regard
to METplus, so please let us know.
Julie
On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Good Morning Julie,
>
> Thanks for the quick response.
>
> I have a feeling the python arrangement on this system could be
where the
> problem is. Given it's an older redhat build (that part I can't get
> around, per IT), python2.7 is the one that's linked/seen by the
system. We
> have python3.7 installed, but a simple command for the python3
config
> doesn't work:
>
> ----------------------------------
> python3-config -ldflags
> python3-config: Command not found.
>
> python3.7-config -ldflags
> python3.7-config: Command not found.
> -------------------------------------------------
>
> Currently, these are how my python environmental variables are
defined in
> the .cshrc:
>
> setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> setenv MET_PYTHON_LD
> '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu -lpython-
config.py'
>
> Perhaps I’m routing that incorrectly?
>
> For reference, here is the listing of the
> /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu Directory;
> -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
>
> For the record, Python.h does exist in /usr/local/include/python3.7m
>
> I realized I had a typo in the filepath for MET_PYTHON_LD the first
time,
> but fixing that hasn’t helped the problem. The new log file is
attached.
>
> I a problem linking python3.7 with the 8.1.2 installation….but let
it
> compile with 2.7 since I wasn’t using python for anything taxing at
the
> time. But given we’ll be leaning on METplus heavily going forward,
I
> wanted to figure this out with the installation of 9.1.
>
> Thanks for looking this over!
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Workoff, Thomas E
Time: Tue Sep 15 11:43:14 2020
Hi Julie,
Realized this morning that I should have sent over the config.log file
for the *apparently* successful configure process, along with the
make_install.log file.
It is attached.
Thanks!
-----Original Message-----
From: Workoff, Thomas E
Sent: Monday, September 14, 2020 1:16 PM
To: met_help at ucar.edu
Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
-- upgrade to MET 9.1 from 8.1.2
Julie...
Ahhhhhhh Ha! I think we're making progress here. Searching for
python3 gave me a few options on this system:
> whereis python3
> python3: /usr/bin/python3.6m /usr/bin/python3.6 /usr/bin/python3
> /usr/lib/python3.6 /usr/lib64/python3.6 /usr/local/bin/python3.7
> /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> /usr/local/lib/python3.7 /usr/include/python3.6m
> /usr/share/man/man1/python3.1.gz
We going to lean on 3.7 here going forward, so I think that's where
our focus should be for this MET install. So, using a full pathname
to identify the cflags and ldflags associated with python3.7 returns
the following:
>/usr/local/bin/python3.7m-config --cflags
-I/usr/local/include/python3.7m -I/usr/local/include/python3.7m -Wno-
unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
/usr/local/bin/python3.7m-config --ldflags
-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
-L/usr/local/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
Using this information, we had a breakthrough! It turns out, I had the
full pathname listed for the ldflag, and I shouldn't have. Replacing
that with simply -lpython3.7m was successful for the configure
Simple, silly problem--but our unorthodox structure of python on this
machine lead to some confusion on my end.
HOWEVER--the make install has failed, and this appears to do with
python3.7. Of course it does, right?? I've included the
make_install.log file for reference. Normally I would spend time
hacking at this to see if I could figure it out without bothering you,
but I'm not familiar at all with where this error may be coming from.
Any ideas??
/usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
//usr/lib64/libdl.so.2: error adding symbols: DSO missing from command
line
collect2: error: ld returned 1 exit status
make[4]: *** [ensemble_stat] Error 1
make[4]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools/core/ensemble_stat'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools/core'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/fewxops/software/met/met-9.1/src/tools'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
make: *** [install-recursive] Error 1
-----Original Message-----
From: Julie Prestopnik via RT <met_help at ucar.edu>
Sent: Monday, September 14, 2020 12:39 PM
To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
-- upgrade to MET 9.1 from 8.1.2
Hi Tom.
Thank you for the additional information and for your new config.log
file.
It looks like Python is still having trouble:
/usr/bin/ld: cannot find -l/usr/local/include/python3.7m
>
> collect2: error: ld returned 1 exit status
>
I have a feeling the python arrangement on this system could be where
the
> problem is.
>
That could very well be. Let's see what we can figure out and try to
get it set up correctly, assuming the Python arrangement is ok on your
system.
Do you know where the python3 executable lives? Perhaps in
/usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping the
"python3-config" executable will be in the same directory and that you
received "python3-config: Command not found." because it was just not
in your path. Being able to run "python3-config --cflags" and
"python3-config --ldflags" will help us know what we should set
MET_PYTHON_CC and MET_PYTHON_LD flags to.
For the record, Python.h does exist in /usr/local/include/python3.7m
>
Hrm. If you run "find /usr/local/ -name Python.h", can you find it?
Currently, these are how my python environmental variables are defined
in
> the .cshrc:
setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> setenv MET_PYTHON_LD
> '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu -lpython-
config.py'
> Perhaps I’m routing that incorrectly?
Typically we wouldn't have "-lpython-config.py", but rather "-
lpython3.7m". There would also typically be other libraries to link
with as well and sometimes another path as well. Here are some
examples from two different machines:
setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\ -lcrypt\
> -lpthread\ -ldl\ -lutil\ -lm
and
export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
-lpython3.6m\
> -lpthread\ -ldl\ -lutil\ -lrt\ -lm
But given we’ll be leaning on METplus heavily going forward, I wanted
to
> figure this out with the installation of 9.1.
We're so glad to hear that you will be using METplus heavily. I hope
we can get the Python embedding functionality working for you. It's
such a great tool to have. We're happy to help with whatever you need
with regard to METplus, so please let us know.
Julie
On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Good Morning Julie,
>
> Thanks for the quick response.
>
> I have a feeling the python arrangement on this system could be
where
> the problem is. Given it's an older redhat build (that part I can't
> get around, per IT), python2.7 is the one that's linked/seen by the
> system. We have python3.7 installed, but a simple command for the
> python3 config doesn't work:
>
> ----------------------------------
> python3-config -ldflags
> python3-config: Command not found.
>
> python3.7-config -ldflags
> python3.7-config: Command not found.
> -------------------------------------------------
>
> Currently, these are how my python environmental variables are
defined
> in the .cshrc:
>
> setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> setenv MET_PYTHON_LD
> '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu -lpython-
config.py'
>
> Perhaps I’m routing that incorrectly?
>
> For reference, here is the listing of the
> /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu Directory;
> -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
>
> For the record, Python.h does exist in /usr/local/include/python3.7m
>
> I realized I had a typo in the filepath for MET_PYTHON_LD the first
> time, but fixing that hasn’t helped the problem. The new log file
is attached.
>
> I a problem linking python3.7 with the 8.1.2 installation….but let
it
> compile with 2.7 since I wasn’t using python for anything taxing at
> the time. But given we’ll be leaning on METplus heavily going
> forward, I wanted to figure this out with the installation of 9.1.
>
> Thanks for looking this over!
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research Research Applications
Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to reply to this email outside of your normal working hours.
------------------------------------------------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Julie Prestopnik
Time: Tue Sep 15 11:51:55 2020
Hi Tom.
I'm so glad you responded with the config.log file. Could you please
resend the make.log file as well? Unfortunately, I never received the
email that you are replying to (that you sent yesterday at 1:16pm. If
you
hadn't this email I wouldn't have known that you responded.
Please send over that make.log file when you get a chance. I have
meetings
for the rest of the day, but hope to take a look at this tomorrow
morning.
I'll follow up as soon as I can.
Julie
On Tue, Sep 15, 2020 at 11:43 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Hi Julie,
>
> Realized this morning that I should have sent over the config.log
file for
> the *apparently* successful configure process, along with the
> make_install.log file.
>
> It is attached.
>
> Thanks!
>
>
>
>
> -----Original Message-----
> From: Workoff, Thomas E
> Sent: Monday, September 14, 2020 1:16 PM
> To: met_help at ucar.edu
> Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
--
> upgrade to MET 9.1 from 8.1.2
>
> Julie...
>
>
> Ahhhhhhh Ha! I think we're making progress here. Searching for
python3
> gave me a few options on this system:
>
>
> > whereis python3
> > python3: /usr/bin/python3.6m /usr/bin/python3.6 /usr/bin/python3
> > /usr/lib/python3.6 /usr/lib64/python3.6 /usr/local/bin/python3.7
> > /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> > /usr/local/lib/python3.7 /usr/include/python3.6m
> > /usr/share/man/man1/python3.1.gz
>
> We going to lean on 3.7 here going forward, so I think that's where
our
> focus should be for this MET install. So, using a full pathname to
> identify the cflags and ldflags associated with python3.7 returns
the
> following:
>
>
> >/usr/local/bin/python3.7m-config --cflags
> -I/usr/local/include/python3.7m -I/usr/local/include/python3.7m
> -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
>
> /usr/local/bin/python3.7m-config --ldflags
> -L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
-L/usr/local/lib
> -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
>
>
> Using this information, we had a breakthrough! It turns out, I had
the
> full pathname listed for the ldflag, and I shouldn't have. Replacing
that
> with simply -lpython3.7m was successful for the configure
>
> Simple, silly problem--but our unorthodox structure of python on
this
> machine lead to some confusion on my end.
>
> HOWEVER--the make install has failed, and this appears to do with
> python3.7. Of course it does, right?? I've included the
make_install.log
> file for reference. Normally I would spend time hacking at this to
see if
> I could figure it out without bothering you, but I'm not familiar at
all
> with where this error may be coming from. Any ideas??
>
> /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
undefined
> reference to symbol 'dlsym@@GLIBC_2.2.5'
> //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
command line
> collect2: error: ld returned 1 exit status
> make[4]: *** [ensemble_stat] Error 1
> make[4]: Leaving directory
> `/fewxops/software/met/met-9.1/src/tools/core/ensemble_stat'
> make[3]: *** [install-recursive] Error 1
> make[3]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools/core'
> make[2]: *** [install-recursive] Error 1
> make[2]: Leaving directory `/fewxops/software/met/met-9.1/src/tools'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
>
> make: *** [install-recursive] Error 1
>
>
>
>
> -----Original Message-----
> From: Julie Prestopnik via RT <met_help at ucar.edu>
> Sent: Monday, September 14, 2020 12:39 PM
> To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
--
> upgrade to MET 9.1 from 8.1.2
>
> Hi Tom.
>
> Thank you for the additional information and for your new config.log
file.
> It looks like Python is still having trouble:
>
> /usr/bin/ld: cannot find -l/usr/local/include/python3.7m
> >
> > collect2: error: ld returned 1 exit status
> >
>
> I have a feeling the python arrangement on this system could be
where the
> > problem is.
> >
> That could very well be. Let's see what we can figure out and try
to get
> it set up correctly, assuming the Python arrangement is ok on your
system.
>
> Do you know where the python3 executable lives? Perhaps in
> /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping the
> "python3-config" executable will be in the same directory and that
you
> received "python3-config: Command not found." because it was just
not in
> your path. Being able to run "python3-config --cflags" and
"python3-config
> --ldflags" will help us know what we should set MET_PYTHON_CC and
> MET_PYTHON_LD flags to.
>
> For the record, Python.h does exist in /usr/local/include/python3.7m
> >
> Hrm. If you run "find /usr/local/ -name Python.h", can you find it?
>
> Currently, these are how my python environmental variables are
defined in
> > the .cshrc:
>
> setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > setenv MET_PYTHON_LD
> > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> -lpython-config.py'
> > Perhaps I’m routing that incorrectly?
>
> Typically we wouldn't have "-lpython-config.py", but rather
> "-lpython3.7m". There would also typically be other libraries to
link with
> as well and sometimes another path as well. Here are some examples
from
> two different machines:
>
> setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\ -lcrypt\
> > -lpthread\ -ldl\ -lutil\ -lm
>
>
> and
>
> export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
-lpython3.6m\
> > -lpthread\ -ldl\ -lutil\ -lrt\ -lm
>
>
>
> But given we’ll be leaning on METplus heavily going forward, I
wanted to
> > figure this out with the installation of 9.1.
>
> We're so glad to hear that you will be using METplus heavily. I
hope we
> can get the Python embedding functionality working for you. It's
such a
> great tool to have. We're happy to help with whatever you need with
regard
> to METplus, so please let us know.
>
> Julie
>
> On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> >
> > Good Morning Julie,
> >
> > Thanks for the quick response.
> >
> > I have a feeling the python arrangement on this system could be
where
> > the problem is. Given it's an older redhat build (that part I
can't
> > get around, per IT), python2.7 is the one that's linked/seen by
the
> > system. We have python3.7 installed, but a simple command for the
> > python3 config doesn't work:
> >
> > ----------------------------------
> > python3-config -ldflags
> > python3-config: Command not found.
> >
> > python3.7-config -ldflags
> > python3.7-config: Command not found.
> > -------------------------------------------------
> >
> > Currently, these are how my python environmental variables are
defined
> > in the .cshrc:
> >
> > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > setenv MET_PYTHON_LD
> > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> -lpython-config.py'
> >
> > Perhaps I’m routing that incorrectly?
> >
> > For reference, here is the listing of the
> > /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu Directory;
> > -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> > -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> > -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> > -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> > -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> > -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> > -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> > -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> > -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> > -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
> >
> > For the record, Python.h does exist in
/usr/local/include/python3.7m
> >
> > I realized I had a typo in the filepath for MET_PYTHON_LD the
first
> > time, but fixing that hasn’t helped the problem. The new log file
is
> attached.
> >
> > I a problem linking python3.7 with the 8.1.2 installation….but let
it
> > compile with 2.7 since I wasn’t using python for anything taxing
at
> > the time. But given we’ll be leaning on METplus heavily going
> > forward, I wanted to figure this out with the installation of 9.1.
> >
> > Thanks for looking this over!
> >
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research Research Applications
Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
>
------------------------------------------------------------------------------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
hereby
> notified that you have received this document in error and that any
review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately, and delete the original message.
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Workoff, Thomas E
Time: Tue Sep 15 11:59:40 2020
Sure thing, it's attached!
If there ends up being any other supporting information you need
(environmental variables, etc), just let me know.
I appreciate your help. No rush!
-----Original Message-----
From: Julie Prestopnik via RT <met_help at ucar.edu>
Sent: Tuesday, September 15, 2020 1:52 PM
To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
-- upgrade to MET 9.1 from 8.1.2
Hi Tom.
I'm so glad you responded with the config.log file. Could you please
resend the make.log file as well? Unfortunately, I never received the
email that you are replying to (that you sent yesterday at 1:16pm. If
you hadn't this email I wouldn't have known that you responded.
Please send over that make.log file when you get a chance. I have
meetings for the rest of the day, but hope to take a look at this
tomorrow morning.
I'll follow up as soon as I can.
Julie
On Tue, Sep 15, 2020 at 11:43 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Hi Julie,
>
> Realized this morning that I should have sent over the config.log
file
> for the *apparently* successful configure process, along with the
> make_install.log file.
>
> It is attached.
>
> Thanks!
>
>
>
>
> -----Original Message-----
> From: Workoff, Thomas E
> Sent: Monday, September 14, 2020 1:16 PM
> To: met_help at ucar.edu
> Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
> -- upgrade to MET 9.1 from 8.1.2
>
> Julie...
>
>
> Ahhhhhhh Ha! I think we're making progress here. Searching for
> python3 gave me a few options on this system:
>
>
> > whereis python3
> > python3: /usr/bin/python3.6m /usr/bin/python3.6 /usr/bin/python3
> > /usr/lib/python3.6 /usr/lib64/python3.6 /usr/local/bin/python3.7
> > /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> > /usr/local/lib/python3.7 /usr/include/python3.6m
> > /usr/share/man/man1/python3.1.gz
>
> We going to lean on 3.7 here going forward, so I think that's where
> our focus should be for this MET install. So, using a full pathname
> to identify the cflags and ldflags associated with python3.7 returns
> the
> following:
>
>
> >/usr/local/bin/python3.7m-config --cflags
> -I/usr/local/include/python3.7m -I/usr/local/include/python3.7m
> -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
>
> /usr/local/bin/python3.7m-config --ldflags
> -L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> -L/usr/local/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
>
>
> Using this information, we had a breakthrough! It turns out, I had
the
> full pathname listed for the ldflag, and I shouldn't have. Replacing
> that with simply -lpython3.7m was successful for the configure
>
> Simple, silly problem--but our unorthodox structure of python on
this
> machine lead to some confusion on my end.
>
> HOWEVER--the make install has failed, and this appears to do with
> python3.7. Of course it does, right?? I've included the
> make_install.log file for reference. Normally I would spend time
> hacking at this to see if I could figure it out without bothering
you,
> but I'm not familiar at all with where this error may be coming
from. Any ideas??
>
> /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
command
> line
> collect2: error: ld returned 1 exit status
> make[4]: *** [ensemble_stat] Error 1
> make[4]: Leaving directory
> `/fewxops/software/met/met-9.1/src/tools/core/ensemble_stat'
> make[3]: *** [install-recursive] Error 1
> make[3]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools/core'
> make[2]: *** [install-recursive] Error 1
> make[2]: Leaving directory `/fewxops/software/met/met-9.1/src/tools'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
>
> make: *** [install-recursive] Error 1
>
>
>
>
> -----Original Message-----
> From: Julie Prestopnik via RT <met_help at ucar.edu>
> Sent: Monday, September 14, 2020 12:39 PM
> To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
> -- upgrade to MET 9.1 from 8.1.2
>
> Hi Tom.
>
> Thank you for the additional information and for your new config.log
file.
> It looks like Python is still having trouble:
>
> /usr/bin/ld: cannot find -l/usr/local/include/python3.7m
> >
> > collect2: error: ld returned 1 exit status
> >
>
> I have a feeling the python arrangement on this system could be
where
> the
> > problem is.
> >
> That could very well be. Let's see what we can figure out and try
to
> get it set up correctly, assuming the Python arrangement is ok on
your system.
>
> Do you know where the python3 executable lives? Perhaps in
> /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping the
> "python3-config" executable will be in the same directory and that
you
> received "python3-config: Command not found." because it was just
not
> in your path. Being able to run "python3-config --cflags" and
> "python3-config --ldflags" will help us know what we should set
> MET_PYTHON_CC and MET_PYTHON_LD flags to.
>
> For the record, Python.h does exist in /usr/local/include/python3.7m
> >
> Hrm. If you run "find /usr/local/ -name Python.h", can you find it?
>
> Currently, these are how my python environmental variables are
defined
> in
> > the .cshrc:
>
> setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > setenv MET_PYTHON_LD
> > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> -lpython-config.py'
> > Perhaps I’m routing that incorrectly?
>
> Typically we wouldn't have "-lpython-config.py", but rather
> "-lpython3.7m". There would also typically be other libraries to
link
> with as well and sometimes another path as well. Here are some
> examples from two different machines:
>
> setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\ -lcrypt\
> > -lpthread\ -ldl\ -lutil\ -lm
>
>
> and
>
> export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
> -lpython3.6m\
> > -lpthread\ -ldl\ -lutil\ -lrt\ -lm
>
>
>
> But given we’ll be leaning on METplus heavily going forward, I
wanted
> to
> > figure this out with the installation of 9.1.
>
> We're so glad to hear that you will be using METplus heavily. I
hope
> we can get the Python embedding functionality working for you. It's
> such a great tool to have. We're happy to help with whatever you
need
> with regard to METplus, so please let us know.
>
> Julie
>
> On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> >
> > Good Morning Julie,
> >
> > Thanks for the quick response.
> >
> > I have a feeling the python arrangement on this system could be
> > where the problem is. Given it's an older redhat build (that part
I
> > can't get around, per IT), python2.7 is the one that's linked/seen
> > by the system. We have python3.7 installed, but a simple command
> > for the
> > python3 config doesn't work:
> >
> > ----------------------------------
> > python3-config -ldflags
> > python3-config: Command not found.
> >
> > python3.7-config -ldflags
> > python3.7-config: Command not found.
> > -------------------------------------------------
> >
> > Currently, these are how my python environmental variables are
> > defined in the .cshrc:
> >
> > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > setenv MET_PYTHON_LD
> > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> -lpython-config.py'
> >
> > Perhaps I’m routing that incorrectly?
> >
> > For reference, here is the listing of the
> > /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu Directory;
> > -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> > -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> > -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> > -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> > -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> > -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> > -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> > -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> > -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> > -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
> >
> > For the record, Python.h does exist in
/usr/local/include/python3.7m
> >
> > I realized I had a typo in the filepath for MET_PYTHON_LD the
first
> > time, but fixing that hasn’t helped the problem. The new log file
> > is
> attached.
> >
> > I a problem linking python3.7 with the 8.1.2 installation….but let
> > it compile with 2.7 since I wasn’t using python for anything
taxing
> > at the time. But given we’ll be leaning on METplus heavily going
> > forward, I wanted to figure this out with the installation of 9.1.
> >
> > Thanks for looking this over!
> >
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research Research Applications
> Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
> obliged to reply to this email outside of your normal working hours.
>
>
>
----------------------------------------------------------------------
> --------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
> hereby notified that you have received this document in error and
that
> any review, dissemination, distribution, or copying of this message
is
> strictly prohibited. If you have received this communication in
error,
> please notify us immediately, and delete the original message.
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research Research Applications
Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to reply to this email outside of your normal working hours.
------------------------------------------------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
------------------------------------------------
Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error -- upgrade to MET 9.1 from 8.1.2
From: Julie Prestopnik
Time: Wed Sep 16 13:16:50 2020
Thank you for all of this information!
I see that you are getting a linker error related to python when
compiling MET:
/usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
//usr/lib64/libdl.so.2: error adding symbols: DSO missing from command
line
Let's have you try setting MET_PYTHON_LD to
export MET_PYTHON_LD=-L/usr/local/lib/python3.7/config-3.7m-
x86_64-linux-gnu\
-L/usr/local/lib\ -lpython3.7m\ -lcrypt\ -lpthread\ -ldl\ -lutil\ -lm
Let's also have you try reconfiguring and compiling without the
“—enable-grib2” option. Let’s make sure there’s no other issues
waiting to be found. Once that successfully compiles we can circle
back and debug the GRIB2 problems.
Please let me know how it goes. I'm also a little concerned about not
having received that other email from you. So, if you respond and I
don't respond within 24 hours, please send me another message to
follow up.
Thanks!
Julie
On Tue, Sep 15, 2020 at 12:00 PM Workoff, Thomas E via RT
<met_help at ucar.edu> wrote:
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Sure thing, it's attached!
>
> If there ends up being any other supporting information you need
(environmental variables, etc), just let me know.
>
> I appreciate your help. No rush!
>
>
> -----Original Message-----
> From: Julie Prestopnik via RT <met_help at ucar.edu>
> Sent: Tuesday, September 15, 2020 1:52 PM
> To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
-- upgrade to MET 9.1 from 8.1.2
>
> Hi Tom.
>
> I'm so glad you responded with the config.log file. Could you
please resend the make.log file as well? Unfortunately, I never
received the email that you are replying to (that you sent yesterday
at 1:16pm. If you hadn't this email I wouldn't have known that you
responded.
>
> Please send over that make.log file when you get a chance. I have
meetings for the rest of the day, but hope to take a look at this
tomorrow morning.
> I'll follow up as soon as I can.
>
> Julie
>
> On Tue, Sep 15, 2020 at 11:43 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> >
> > Hi Julie,
> >
> > Realized this morning that I should have sent over the config.log
file
> > for the *apparently* successful configure process, along with the
> > make_install.log file.
> >
> > It is attached.
> >
> > Thanks!
> >
> >
> >
> >
> > -----Original Message-----
> > From: Workoff, Thomas E
> > Sent: Monday, September 14, 2020 1:16 PM
> > To: met_help at ucar.edu
> > Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > -- upgrade to MET 9.1 from 8.1.2
> >
> > Julie...
> >
> >
> > Ahhhhhhh Ha! I think we're making progress here. Searching for
> > python3 gave me a few options on this system:
> >
> >
> > > whereis python3
> > > python3: /usr/bin/python3.6m /usr/bin/python3.6 /usr/bin/python3
> > > /usr/lib/python3.6 /usr/lib64/python3.6 /usr/local/bin/python3.7
> > > /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> > > /usr/local/lib/python3.7 /usr/include/python3.6m
> > > /usr/share/man/man1/python3.1.gz
> >
> > We going to lean on 3.7 here going forward, so I think that's
where
> > our focus should be for this MET install. So, using a full
pathname
> > to identify the cflags and ldflags associated with python3.7
returns
> > the
> > following:
> >
> >
> > >/usr/local/bin/python3.7m-config --cflags
> > -I/usr/local/include/python3.7m -I/usr/local/include/python3.7m
> > -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
> >
> > /usr/local/bin/python3.7m-config --ldflags
> > -L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > -L/usr/local/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
> >
> >
> > Using this information, we had a breakthrough! It turns out, I had
the
> > full pathname listed for the ldflag, and I shouldn't have.
Replacing
> > that with simply -lpython3.7m was successful for the configure
> >
> > Simple, silly problem--but our unorthodox structure of python on
this
> > machine lead to some confusion on my end.
> >
> > HOWEVER--the make install has failed, and this appears to do with
> > python3.7. Of course it does, right?? I've included the
> > make_install.log file for reference. Normally I would spend time
> > hacking at this to see if I could figure it out without bothering
you,
> > but I'm not familiar at all with where this error may be coming
from. Any ideas??
> >
> > /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> > undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> > //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
command
> > line
> > collect2: error: ld returned 1 exit status
> > make[4]: *** [ensemble_stat] Error 1
> > make[4]: Leaving directory
> > `/fewxops/software/met/met-9.1/src/tools/core/ensemble_stat'
> > make[3]: *** [install-recursive] Error 1
> > make[3]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools/core'
> > make[2]: *** [install-recursive] Error 1
> > make[2]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools'
> > make[1]: *** [install-recursive] Error 1
> > make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
> >
> > make: *** [install-recursive] Error 1
> >
> >
> >
> >
> > -----Original Message-----
> > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > Sent: Monday, September 14, 2020 12:39 PM
> > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > -- upgrade to MET 9.1 from 8.1.2
> >
> > Hi Tom.
> >
> > Thank you for the additional information and for your new
config.log file.
> > It looks like Python is still having trouble:
> >
> > /usr/bin/ld: cannot find -l/usr/local/include/python3.7m
> > >
> > > collect2: error: ld returned 1 exit status
> > >
> >
> > I have a feeling the python arrangement on this system could be
where
> > the
> > > problem is.
> > >
> > That could very well be. Let's see what we can figure out and try
to
> > get it set up correctly, assuming the Python arrangement is ok on
your system.
> >
> > Do you know where the python3 executable lives? Perhaps in
> > /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping the
> > "python3-config" executable will be in the same directory and that
you
> > received "python3-config: Command not found." because it was just
not
> > in your path. Being able to run "python3-config --cflags" and
> > "python3-config --ldflags" will help us know what we should set
> > MET_PYTHON_CC and MET_PYTHON_LD flags to.
> >
> > For the record, Python.h does exist in
/usr/local/include/python3.7m
> > >
> > Hrm. If you run "find /usr/local/ -name Python.h", can you find
it?
> >
> > Currently, these are how my python environmental variables are
defined
> > in
> > > the .cshrc:
> >
> > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > setenv MET_PYTHON_LD
> > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > -lpython-config.py'
> > > Perhaps I’m routing that incorrectly?
> >
> > Typically we wouldn't have "-lpython-config.py", but rather
> > "-lpython3.7m". There would also typically be other libraries to
link
> > with as well and sometimes another path as well. Here are some
> > examples from two different machines:
> >
> > setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\
-lcrypt\
> > > -lpthread\ -ldl\ -lutil\ -lm
> >
> >
> > and
> >
> > export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
> > -lpython3.6m\
> > > -lpthread\ -ldl\ -lutil\ -lrt\ -lm
> >
> >
> >
> > But given we’ll be leaning on METplus heavily going forward, I
wanted
> > to
> > > figure this out with the installation of 9.1.
> >
> > We're so glad to hear that you will be using METplus heavily. I
hope
> > we can get the Python embedding functionality working for you.
It's
> > such a great tool to have. We're happy to help with whatever you
need
> > with regard to METplus, so please let us know.
> >
> > Julie
> >
> > On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> > >
> > > Good Morning Julie,
> > >
> > > Thanks for the quick response.
> > >
> > > I have a feeling the python arrangement on this system could be
> > > where the problem is. Given it's an older redhat build (that
part I
> > > can't get around, per IT), python2.7 is the one that's
linked/seen
> > > by the system. We have python3.7 installed, but a simple
command
> > > for the
> > > python3 config doesn't work:
> > >
> > > ----------------------------------
> > > python3-config -ldflags
> > > python3-config: Command not found.
> > >
> > > python3.7-config -ldflags
> > > python3.7-config: Command not found.
> > > -------------------------------------------------
> > >
> > > Currently, these are how my python environmental variables are
> > > defined in the .cshrc:
> > >
> > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > setenv MET_PYTHON_LD
> > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > -lpython-config.py'
> > >
> > > Perhaps I’m routing that incorrectly?
> > >
> > > For reference, here is the listing of the
> > > /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu Directory;
> > > -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> > > -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> > > -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> > > -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> > > -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> > > -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> > > -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> > > -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> > > -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> > > -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
> > >
> > > For the record, Python.h does exist in
/usr/local/include/python3.7m
> > >
> > > I realized I had a typo in the filepath for MET_PYTHON_LD the
first
> > > time, but fixing that hasn’t helped the problem. The new log
file
> > > is
> > attached.
> > >
> > > I a problem linking python3.7 with the 8.1.2 installation….but
let
> > > it compile with 2.7 since I wasn’t using python for anything
taxing
> > > at the time. But given we’ll be leaning on METplus heavily
going
> > > forward, I wanted to figure this out with the installation of
9.1.
> > >
> > > Thanks for looking this over!
> > >
> >
> > --
> > Julie Prestopnik (she/her/hers)
> > Software Engineer
> > National Center for Atmospheric Research Research Applications
> > Laboratory
> > Phone: 303.497.8399
> > Email: jpresto at ucar.edu
> >
> > My working day may not be your working day. Please do not feel
> > obliged to reply to this email outside of your normal working
hours.
> >
> >
> >
----------------------------------------------------------------------
> > --------
> >
> > The information contained in this message is intended only for the
> > personal and confidential use of the recipient(s) named above. If
the
> > reader of this message is not the intended recipient or an agent
> > responsible for delivering it to the intended recipient, you are
> > hereby notified that you have received this document in error and
that
> > any review, dissemination, distribution, or copying of this
message is
> > strictly prohibited. If you have received this communication in
error,
> > please notify us immediately, and delete the original message.
> >
> >
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research Research Applications
Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
obliged to reply to this email outside of your normal working hours.
>
>
------------------------------------------------------------------------------
>
> The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to reply to this email outside of your normal working hours.
------------------------------------------------
Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error -- upgrade to MET 9.1 from 8.1.2
From: Workoff, Thomas E
Time: Thu Sep 17 08:06:38 2020
Julie--
Success! (I think).
The updated python LD reference did the trick. I reconfigured and
installed with simply python and mode graphics activated, and things
appear to have run smoothly. I then backtracked and added grib2
functionality, and still appear to be successful.
I really appreciate all your help on this!
I'll now work through making the adjustments needed to run 9.1 from
8.1.2.
On an unrelated note: does there happen to be a script repository or
references available for the plotting of MET output data (such as the
plots shown in chapter 25 of the User's Manual)? I can put together
plots myself via python or R, but I'm just wondering if there's
something available in the community to help streamline that process.
On a second semi-related note: it does appear my original email was
sent. I was wondering if, with all the VPN and working remotely
drama, if perhaps my email got stuck in my outbox and was never
actually sent to you. But, it appears it was indeed sent out. So, it
may be one of the big mysteries of the universe as to how it never
made it to you! Regardless, I appreciate you working through all the
issues with me.
Thanks!
-Tom
-----Original Message-----
From: Julie Prestopnik via RT <met_help at ucar.edu>
Sent: Wednesday, September 16, 2020 3:17 PM
To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
-- upgrade to MET 9.1 from 8.1.2
Thank you for all of this information!
I see that you are getting a linker error related to python when
compiling MET:
/usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
//usr/lib64/libdl.so.2: error adding symbols: DSO missing from command
line
Let's have you try setting MET_PYTHON_LD to
export MET_PYTHON_LD=-L/usr/local/lib/python3.7/config-3.7m-
x86_64-linux-gnu\
-L/usr/local/lib\ -lpython3.7m\ -lcrypt\ -lpthread\ -ldl\ -lutil\ -lm
Let's also have you try reconfiguring and compiling without the
“—enable-grib2” option. Let’s make sure there’s no other issues
waiting to be found. Once that successfully compiles we can circle
back and debug the GRIB2 problems.
Please let me know how it goes. I'm also a little concerned about not
having received that other email from you. So, if you respond and I
don't respond within 24 hours, please send me another message to
follow up.
Thanks!
Julie
On Tue, Sep 15, 2020 at 12:00 PM Workoff, Thomas E via RT
<met_help at ucar.edu> wrote:
>
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Sure thing, it's attached!
>
> If there ends up being any other supporting information you need
(environmental variables, etc), just let me know.
>
> I appreciate your help. No rush!
>
>
> -----Original Message-----
> From: Julie Prestopnik via RT <met_help at ucar.edu>
> Sent: Tuesday, September 15, 2020 1:52 PM
> To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
> -- upgrade to MET 9.1 from 8.1.2
>
> Hi Tom.
>
> I'm so glad you responded with the config.log file. Could you
please resend the make.log file as well? Unfortunately, I never
received the email that you are replying to (that you sent yesterday
at 1:16pm. If you hadn't this email I wouldn't have known that you
responded.
>
> Please send over that make.log file when you get a chance. I have
meetings for the rest of the day, but hope to take a look at this
tomorrow morning.
> I'll follow up as soon as I can.
>
> Julie
>
> On Tue, Sep 15, 2020 at 11:43 AM Workoff, Thomas E via RT
> <met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> >
> > Hi Julie,
> >
> > Realized this morning that I should have sent over the config.log
> > file for the *apparently* successful configure process, along with
> > the make_install.log file.
> >
> > It is attached.
> >
> > Thanks!
> >
> >
> >
> >
> > -----Original Message-----
> > From: Workoff, Thomas E
> > Sent: Monday, September 14, 2020 1:16 PM
> > To: met_help at ucar.edu
> > Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > -- upgrade to MET 9.1 from 8.1.2
> >
> > Julie...
> >
> >
> > Ahhhhhhh Ha! I think we're making progress here. Searching for
> > python3 gave me a few options on this system:
> >
> >
> > > whereis python3
> > > python3: /usr/bin/python3.6m /usr/bin/python3.6 /usr/bin/python3
> > > /usr/lib/python3.6 /usr/lib64/python3.6 /usr/local/bin/python3.7
> > > /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> > > /usr/local/lib/python3.7 /usr/include/python3.6m
> > > /usr/share/man/man1/python3.1.gz
> >
> > We going to lean on 3.7 here going forward, so I think that's
where
> > our focus should be for this MET install. So, using a full
pathname
> > to identify the cflags and ldflags associated with python3.7
returns
> > the
> > following:
> >
> >
> > >/usr/local/bin/python3.7m-config --cflags
> > -I/usr/local/include/python3.7m -I/usr/local/include/python3.7m
> > -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
> >
> > /usr/local/bin/python3.7m-config --ldflags
> > -L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > -L/usr/local/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
> >
> >
> > Using this information, we had a breakthrough! It turns out, I had
> > the full pathname listed for the ldflag, and I shouldn't have.
> > Replacing that with simply -lpython3.7m was successful for the
> > configure
> >
> > Simple, silly problem--but our unorthodox structure of python on
> > this machine lead to some confusion on my end.
> >
> > HOWEVER--the make install has failed, and this appears to do with
> > python3.7. Of course it does, right?? I've included the
> > make_install.log file for reference. Normally I would spend time
> > hacking at this to see if I could figure it out without bothering
> > you, but I'm not familiar at all with where this error may be
coming from. Any ideas??
> >
> > /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> > undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> > //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
> > command line
> > collect2: error: ld returned 1 exit status
> > make[4]: *** [ensemble_stat] Error 1
> > make[4]: Leaving directory
> > `/fewxops/software/met/met-9.1/src/tools/core/ensemble_stat'
> > make[3]: *** [install-recursive] Error 1
> > make[3]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools/core'
> > make[2]: *** [install-recursive] Error 1
> > make[2]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools'
> > make[1]: *** [install-recursive] Error 1
> > make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
> >
> > make: *** [install-recursive] Error 1
> >
> >
> >
> >
> > -----Original Message-----
> > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > Sent: Monday, September 14, 2020 12:39 PM
> > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > -- upgrade to MET 9.1 from 8.1.2
> >
> > Hi Tom.
> >
> > Thank you for the additional information and for your new
config.log file.
> > It looks like Python is still having trouble:
> >
> > /usr/bin/ld: cannot find -l/usr/local/include/python3.7m
> > >
> > > collect2: error: ld returned 1 exit status
> > >
> >
> > I have a feeling the python arrangement on this system could be
> > where the
> > > problem is.
> > >
> > That could very well be. Let's see what we can figure out and try
> > to get it set up correctly, assuming the Python arrangement is ok
on your system.
> >
> > Do you know where the python3 executable lives? Perhaps in
> > /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping the
> > "python3-config" executable will be in the same directory and that
> > you received "python3-config: Command not found." because it was
> > just not in your path. Being able to run "python3-config
--cflags"
> > and "python3-config --ldflags" will help us know what we should
set
> > MET_PYTHON_CC and MET_PYTHON_LD flags to.
> >
> > For the record, Python.h does exist in
/usr/local/include/python3.7m
> > >
> > Hrm. If you run "find /usr/local/ -name Python.h", can you find
it?
> >
> > Currently, these are how my python environmental variables are
> > defined in
> > > the .cshrc:
> >
> > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > setenv MET_PYTHON_LD
> > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > -lpython-config.py'
> > > Perhaps I’m routing that incorrectly?
> >
> > Typically we wouldn't have "-lpython-config.py", but rather
> > "-lpython3.7m". There would also typically be other libraries to
> > link with as well and sometimes another path as well. Here are
some
> > examples from two different machines:
> >
> > setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\
-lcrypt\
> > > -lpthread\ -ldl\ -lutil\ -lm
> >
> >
> > and
> >
> > export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
> > -lpython3.6m\
> > > -lpthread\ -ldl\ -lutil\ -lrt\ -lm
> >
> >
> >
> > But given we’ll be leaning on METplus heavily going forward, I
> > wanted to
> > > figure this out with the installation of 9.1.
> >
> > We're so glad to hear that you will be using METplus heavily. I
> > hope we can get the Python embedding functionality working for
you.
> > It's such a great tool to have. We're happy to help with whatever
> > you need with regard to METplus, so please let us know.
> >
> > Julie
> >
> > On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> > >
> > > Good Morning Julie,
> > >
> > > Thanks for the quick response.
> > >
> > > I have a feeling the python arrangement on this system could be
> > > where the problem is. Given it's an older redhat build (that
part
> > > I can't get around, per IT), python2.7 is the one that's
> > > linked/seen by the system. We have python3.7 installed, but a
> > > simple command for the
> > > python3 config doesn't work:
> > >
> > > ----------------------------------
> > > python3-config -ldflags
> > > python3-config: Command not found.
> > >
> > > python3.7-config -ldflags
> > > python3.7-config: Command not found.
> > > -------------------------------------------------
> > >
> > > Currently, these are how my python environmental variables are
> > > defined in the .cshrc:
> > >
> > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > setenv MET_PYTHON_LD
> > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > -lpython-config.py'
> > >
> > > Perhaps I’m routing that incorrectly?
> > >
> > > For reference, here is the listing of the
> > > /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu Directory;
> > > -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> > > -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> > > -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> > > -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> > > -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> > > -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> > > -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> > > -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> > > -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> > > -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
> > >
> > > For the record, Python.h does exist in
> > > /usr/local/include/python3.7m
> > >
> > > I realized I had a typo in the filepath for MET_PYTHON_LD the
> > > first time, but fixing that hasn’t helped the problem. The new
> > > log file is
> > attached.
> > >
> > > I a problem linking python3.7 with the 8.1.2 installation….but
let
> > > it compile with 2.7 since I wasn’t using python for anything
> > > taxing at the time. But given we’ll be leaning on METplus
heavily
> > > going forward, I wanted to figure this out with the installation
of 9.1.
> > >
> > > Thanks for looking this over!
> > >
> >
> > --
> > Julie Prestopnik (she/her/hers)
> > Software Engineer
> > National Center for Atmospheric Research Research Applications
> > Laboratory
> > Phone: 303.497.8399
> > Email: jpresto at ucar.edu
> >
> > My working day may not be your working day. Please do not feel
> > obliged to reply to this email outside of your normal working
hours.
> >
> >
> >
--------------------------------------------------------------------
> > --
> > --------
> >
> > The information contained in this message is intended only for the
> > personal and confidential use of the recipient(s) named above. If
> > the reader of this message is not the intended recipient or an
agent
> > responsible for delivering it to the intended recipient, you are
> > hereby notified that you have received this document in error and
> > that any review, dissemination, distribution, or copying of this
> > message is strictly prohibited. If you have received this
> > communication in error, please notify us immediately, and delete
the original message.
> >
> >
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research Research Applications
> Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
obliged to reply to this email outside of your normal working hours.
>
>
----------------------------------------------------------------------
> --------
>
> The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research Research Applications
Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to reply to this email outside of your normal working hours.
------------------------------------------------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Julie Prestopnik
Time: Thu Sep 17 09:16:56 2020
Hi Tom.
Great news! Thanks so much for letting me know.
I will have a colleague follow up with you regarding your question
about
plotting.
Thanks for letting me know about your original email. We did have
some
issues with a power outage recently, but I thought those problems were
resolved when you sent your email. It's unclear what the issue was
exactly, but I'm so glad that you followed up, and that everything
seems to
be ok now. I guess a thought to take away from this experience is to
definitely follow up if you don't hear back from us in a timely
manner.
Julie
On Thu, Sep 17, 2020 at 8:06 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Julie--
>
> Success! (I think).
>
> The updated python LD reference did the trick. I reconfigured and
> installed with simply python and mode graphics activated, and things
appear
> to have run smoothly. I then backtracked and added grib2
functionality,
> and still appear to be successful.
>
> I really appreciate all your help on this!
>
> I'll now work through making the adjustments needed to run 9.1 from
8.1.2.
>
> On an unrelated note: does there happen to be a script repository or
> references available for the plotting of MET output data (such as
the plots
> shown in chapter 25 of the User's Manual)? I can put together plots
myself
> via python or R, but I'm just wondering if there's something
available in
> the community to help streamline that process.
>
> On a second semi-related note: it does appear my original email was
sent.
> I was wondering if, with all the VPN and working remotely drama, if
perhaps
> my email got stuck in my outbox and was never actually sent to you.
But,
> it appears it was indeed sent out. So, it may be one of the big
mysteries
> of the universe as to how it never made it to you! Regardless, I
> appreciate you working through all the issues with me.
>
> Thanks!
> -Tom
>
>
>
>
>
> -----Original Message-----
> From: Julie Prestopnik via RT <met_help at ucar.edu>
> Sent: Wednesday, September 16, 2020 3:17 PM
> To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
--
> upgrade to MET 9.1 from 8.1.2
>
> Thank you for all of this information!
>
> I see that you are getting a linker error related to python when
compiling
> MET:
>
> /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
command line
>
> Let's have you try setting MET_PYTHON_LD to
>
> export
> MET_PYTHON_LD=-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-
gnu\
> -L/usr/local/lib\ -lpython3.7m\ -lcrypt\ -lpthread\ -ldl\ -lutil\
-lm
>
> Let's also have you try reconfiguring and compiling without the
> “—enable-grib2” option. Let’s make sure there’s no other issues
waiting to
> be found. Once that successfully compiles we can circle back and
debug the
> GRIB2 problems.
>
> Please let me know how it goes. I'm also a little concerned about
not
> having received that other email from you. So, if you respond and I
don't
> respond within 24 hours, please send me another message to follow
up.
>
> Thanks!
>
> Julie
>
> On Tue, Sep 15, 2020 at 12:00 PM Workoff, Thomas E via RT <
> met_help at ucar.edu> wrote:
> >
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> >
> > Sure thing, it's attached!
> >
> > If there ends up being any other supporting information you need
> (environmental variables, etc), just let me know.
> >
> > I appreciate your help. No rush!
> >
> >
> > -----Original Message-----
> > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > Sent: Tuesday, September 15, 2020 1:52 PM
> > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > -- upgrade to MET 9.1 from 8.1.2
> >
> > Hi Tom.
> >
> > I'm so glad you responded with the config.log file. Could you
please
> resend the make.log file as well? Unfortunately, I never received
the
> email that you are replying to (that you sent yesterday at 1:16pm.
If you
> hadn't this email I wouldn't have known that you responded.
> >
> > Please send over that make.log file when you get a chance. I have
> meetings for the rest of the day, but hope to take a look at this
tomorrow
> morning.
> > I'll follow up as soon as I can.
> >
> > Julie
> >
> > On Tue, Sep 15, 2020 at 11:43 AM Workoff, Thomas E via RT
> > <met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> > >
> > > Hi Julie,
> > >
> > > Realized this morning that I should have sent over the
config.log
> > > file for the *apparently* successful configure process, along
with
> > > the make_install.log file.
> > >
> > > It is attached.
> > >
> > > Thanks!
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Workoff, Thomas E
> > > Sent: Monday, September 14, 2020 1:16 PM
> > > To: met_help at ucar.edu
> > > Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > > -- upgrade to MET 9.1 from 8.1.2
> > >
> > > Julie...
> > >
> > >
> > > Ahhhhhhh Ha! I think we're making progress here. Searching for
> > > python3 gave me a few options on this system:
> > >
> > >
> > > > whereis python3
> > > > python3: /usr/bin/python3.6m /usr/bin/python3.6
/usr/bin/python3
> > > > /usr/lib/python3.6 /usr/lib64/python3.6
/usr/local/bin/python3.7
> > > > /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> > > > /usr/local/lib/python3.7 /usr/include/python3.6m
> > > > /usr/share/man/man1/python3.1.gz
> > >
> > > We going to lean on 3.7 here going forward, so I think that's
where
> > > our focus should be for this MET install. So, using a full
pathname
> > > to identify the cflags and ldflags associated with python3.7
returns
> > > the
> > > following:
> > >
> > >
> > > >/usr/local/bin/python3.7m-config --cflags
> > > -I/usr/local/include/python3.7m -I/usr/local/include/python3.7m
> > > -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
> > >
> > > /usr/local/bin/python3.7m-config --ldflags
> > > -L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -L/usr/local/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
> > >
> > >
> > > Using this information, we had a breakthrough! It turns out, I
had
> > > the full pathname listed for the ldflag, and I shouldn't have.
> > > Replacing that with simply -lpython3.7m was successful for the
> > > configure
> > >
> > > Simple, silly problem--but our unorthodox structure of python on
> > > this machine lead to some confusion on my end.
> > >
> > > HOWEVER--the make install has failed, and this appears to do
with
> > > python3.7. Of course it does, right?? I've included the
> > > make_install.log file for reference. Normally I would spend
time
> > > hacking at this to see if I could figure it out without
bothering
> > > you, but I'm not familiar at all with where this error may be
coming
> from. Any ideas??
> > >
> > > /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> > > undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> > > //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
> > > command line
> > > collect2: error: ld returned 1 exit status
> > > make[4]: *** [ensemble_stat] Error 1
> > > make[4]: Leaving directory
> > > `/fewxops/software/met/met-9.1/src/tools/core/ensemble_stat'
> > > make[3]: *** [install-recursive] Error 1
> > > make[3]: Leaving directory
> `/fewxops/software/met/met-9.1/src/tools/core'
> > > make[2]: *** [install-recursive] Error 1
> > > make[2]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools'
> > > make[1]: *** [install-recursive] Error 1
> > > make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
> > >
> > > make: *** [install-recursive] Error 1
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > > Sent: Monday, September 14, 2020 12:39 PM
> > > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > > -- upgrade to MET 9.1 from 8.1.2
> > >
> > > Hi Tom.
> > >
> > > Thank you for the additional information and for your new
config.log
> file.
> > > It looks like Python is still having trouble:
> > >
> > > /usr/bin/ld: cannot find -l/usr/local/include/python3.7m
> > > >
> > > > collect2: error: ld returned 1 exit status
> > > >
> > >
> > > I have a feeling the python arrangement on this system could be
> > > where the
> > > > problem is.
> > > >
> > > That could very well be. Let's see what we can figure out and
try
> > > to get it set up correctly, assuming the Python arrangement is
ok on
> your system.
> > >
> > > Do you know where the python3 executable lives? Perhaps in
> > > /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping
the
> > > "python3-config" executable will be in the same directory and
that
> > > you received "python3-config: Command not found." because it was
> > > just not in your path. Being able to run "python3-config
--cflags"
> > > and "python3-config --ldflags" will help us know what we should
set
> > > MET_PYTHON_CC and MET_PYTHON_LD flags to.
> > >
> > > For the record, Python.h does exist in
/usr/local/include/python3.7m
> > > >
> > > Hrm. If you run "find /usr/local/ -name Python.h", can you find
it?
> > >
> > > Currently, these are how my python environmental variables are
> > > defined in
> > > > the .cshrc:
> > >
> > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > > setenv MET_PYTHON_LD
> > > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -lpython-config.py'
> > > > Perhaps I’m routing that incorrectly?
> > >
> > > Typically we wouldn't have "-lpython-config.py", but rather
> > > "-lpython3.7m". There would also typically be other libraries
to
> > > link with as well and sometimes another path as well. Here are
some
> > > examples from two different machines:
> > >
> > > setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\
-lcrypt\
> > > > -lpthread\ -ldl\ -lutil\ -lm
> > >
> > >
> > > and
> > >
> > > export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
> > > -lpython3.6m\
> > > > -lpthread\ -ldl\ -lutil\ -lrt\ -lm
> > >
> > >
> > >
> > > But given we’ll be leaning on METplus heavily going forward, I
> > > wanted to
> > > > figure this out with the installation of 9.1.
> > >
> > > We're so glad to hear that you will be using METplus heavily. I
> > > hope we can get the Python embedding functionality working for
you.
> > > It's such a great tool to have. We're happy to help with
whatever
> > > you need with regard to METplus, so please let us know.
> > >
> > > Julie
> > >
> > > On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693
>
> > > >
> > > > Good Morning Julie,
> > > >
> > > > Thanks for the quick response.
> > > >
> > > > I have a feeling the python arrangement on this system could
be
> > > > where the problem is. Given it's an older redhat build (that
part
> > > > I can't get around, per IT), python2.7 is the one that's
> > > > linked/seen by the system. We have python3.7 installed, but a
> > > > simple command for the
> > > > python3 config doesn't work:
> > > >
> > > > ----------------------------------
> > > > python3-config -ldflags
> > > > python3-config: Command not found.
> > > >
> > > > python3.7-config -ldflags
> > > > python3.7-config: Command not found.
> > > > -------------------------------------------------
> > > >
> > > > Currently, these are how my python environmental variables are
> > > > defined in the .cshrc:
> > > >
> > > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > > setenv MET_PYTHON_LD
> > > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -lpython-config.py'
> > > >
> > > > Perhaps I’m routing that incorrectly?
> > > >
> > > > For reference, here is the listing of the
> > > > /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
Directory;
> > > > -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> > > > -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> > > > -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> > > > -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> > > > -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> > > > -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> > > > -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> > > > -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> > > > -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> > > > -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
> > > >
> > > > For the record, Python.h does exist in
> > > > /usr/local/include/python3.7m
> > > >
> > > > I realized I had a typo in the filepath for MET_PYTHON_LD the
> > > > first time, but fixing that hasn’t helped the problem. The
new
> > > > log file is
> > > attached.
> > > >
> > > > I a problem linking python3.7 with the 8.1.2 installation….but
let
> > > > it compile with 2.7 since I wasn’t using python for anything
> > > > taxing at the time. But given we’ll be leaning on METplus
heavily
> > > > going forward, I wanted to figure this out with the
installation of
> 9.1.
> > > >
> > > > Thanks for looking this over!
> > > >
> > >
> > > --
> > > Julie Prestopnik (she/her/hers)
> > > Software Engineer
> > > National Center for Atmospheric Research Research Applications
> > > Laboratory
> > > Phone: 303.497.8399
> > > Email: jpresto at ucar.edu
> > >
> > > My working day may not be your working day. Please do not feel
> > > obliged to reply to this email outside of your normal working
hours.
> > >
> > >
> > >
--------------------------------------------------------------------
> > > --
> > > --------
> > >
> > > The information contained in this message is intended only for
the
> > > personal and confidential use of the recipient(s) named above.
If
> > > the reader of this message is not the intended recipient or an
agent
> > > responsible for delivering it to the intended recipient, you are
> > > hereby notified that you have received this document in error
and
> > > that any review, dissemination, distribution, or copying of this
> > > message is strictly prohibited. If you have received this
> > > communication in error, please notify us immediately, and delete
the
> original message.
> > >
> > >
> >
> > --
> > Julie Prestopnik (she/her/hers)
> > Software Engineer
> > National Center for Atmospheric Research Research Applications
> > Laboratory
> > Phone: 303.497.8399
> > Email: jpresto at ucar.edu
> >
> > My working day may not be your working day. Please do not feel
obliged
> to reply to this email outside of your normal working hours.
> >
> >
----------------------------------------------------------------------
> > --------
> >
> > The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
hereby
> notified that you have received this document in error and that any
review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately, and delete the original message.
> >
>
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research Research Applications
Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
>
>
------------------------------------------------------------------------------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
hereby
> notified that you have received this document in error and that any
review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately, and delete the original message.
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Minna Win
Time: Thu Sep 17 09:58:23 2020
Hi Tom,
The R scripts that are currently available for viewing MET output are
located in the MET repository:
https://github.com/dtcenter/MET/tree/master_v9.1/met/scripts/Rscripts
We are currently working on replacing the R scripts (with python) that
are
currently used in METviewer. The code under construction can be
found in
the METplotpy repository: https://github.com/dtcenter/METplotpy. We
have a
scheduled 1.0 release in March 2021. Our documentation is not as
mature
(and in some instances non-existent at this point) as the MET and
METplus
wrappers documentation. Hopefully you can find some of the existing
code
to be useful. If you make any modifications or have any novel
plotting
scripts, we'd welcome any contribution. Some of the plots are
implemented
in matplotlib. We are striving to have the plots implemented in
python
plotly for interactivity (whenever possible).
I hope that helps answer your question.
Regards,
Minna
---------------
Minna Win
National Center for Atmospheric Research
Developmental Testbed Center
Phone: 303-497-8423
Fax: 303-497-8401
On Thu, Sep 17, 2020 at 8:06 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Julie--
>
> Success! (I think).
>
> The updated python LD reference did the trick. I reconfigured and
> installed with simply python and mode graphics activated, and things
appear
> to have run smoothly. I then backtracked and added grib2
functionality,
> and still appear to be successful.
>
> I really appreciate all your help on this!
>
> I'll now work through making the adjustments needed to run 9.1 from
8.1.2.
>
> On an unrelated note: does there happen to be a script repository or
> references available for the plotting of MET output data (such as
the plots
> shown in chapter 25 of the User's Manual)? I can put together plots
myself
> via python or R, but I'm just wondering if there's something
available in
> the community to help streamline that process.
>
> On a second semi-related note: it does appear my original email was
sent.
> I was wondering if, with all the VPN and working remotely drama, if
perhaps
> my email got stuck in my outbox and was never actually sent to you.
But,
> it appears it was indeed sent out. So, it may be one of the big
mysteries
> of the universe as to how it never made it to you! Regardless, I
> appreciate you working through all the issues with me.
>
> Thanks!
> -Tom
>
>
>
>
>
> -----Original Message-----
> From: Julie Prestopnik via RT <met_help at ucar.edu>
> Sent: Wednesday, September 16, 2020 3:17 PM
> To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
--
> upgrade to MET 9.1 from 8.1.2
>
> Thank you for all of this information!
>
> I see that you are getting a linker error related to python when
compiling
> MET:
>
> /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
command line
>
> Let's have you try setting MET_PYTHON_LD to
>
> export
> MET_PYTHON_LD=-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-
gnu\
> -L/usr/local/lib\ -lpython3.7m\ -lcrypt\ -lpthread\ -ldl\ -lutil\
-lm
>
> Let's also have you try reconfiguring and compiling without the
> “—enable-grib2” option. Let’s make sure there’s no other issues
waiting to
> be found. Once that successfully compiles we can circle back and
debug the
> GRIB2 problems.
>
> Please let me know how it goes. I'm also a little concerned about
not
> having received that other email from you. So, if you respond and I
don't
> respond within 24 hours, please send me another message to follow
up.
>
> Thanks!
>
> Julie
>
> On Tue, Sep 15, 2020 at 12:00 PM Workoff, Thomas E via RT <
> met_help at ucar.edu> wrote:
> >
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> >
> > Sure thing, it's attached!
> >
> > If there ends up being any other supporting information you need
> (environmental variables, etc), just let me know.
> >
> > I appreciate your help. No rush!
> >
> >
> > -----Original Message-----
> > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > Sent: Tuesday, September 15, 2020 1:52 PM
> > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > -- upgrade to MET 9.1 from 8.1.2
> >
> > Hi Tom.
> >
> > I'm so glad you responded with the config.log file. Could you
please
> resend the make.log file as well? Unfortunately, I never received
the
> email that you are replying to (that you sent yesterday at 1:16pm.
If you
> hadn't this email I wouldn't have known that you responded.
> >
> > Please send over that make.log file when you get a chance. I have
> meetings for the rest of the day, but hope to take a look at this
tomorrow
> morning.
> > I'll follow up as soon as I can.
> >
> > Julie
> >
> > On Tue, Sep 15, 2020 at 11:43 AM Workoff, Thomas E via RT
> > <met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> > >
> > > Hi Julie,
> > >
> > > Realized this morning that I should have sent over the
config.log
> > > file for the *apparently* successful configure process, along
with
> > > the make_install.log file.
> > >
> > > It is attached.
> > >
> > > Thanks!
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Workoff, Thomas E
> > > Sent: Monday, September 14, 2020 1:16 PM
> > > To: met_help at ucar.edu
> > > Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > > -- upgrade to MET 9.1 from 8.1.2
> > >
> > > Julie...
> > >
> > >
> > > Ahhhhhhh Ha! I think we're making progress here. Searching for
> > > python3 gave me a few options on this system:
> > >
> > >
> > > > whereis python3
> > > > python3: /usr/bin/python3.6m /usr/bin/python3.6
/usr/bin/python3
> > > > /usr/lib/python3.6 /usr/lib64/python3.6
/usr/local/bin/python3.7
> > > > /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> > > > /usr/local/lib/python3.7 /usr/include/python3.6m
> > > > /usr/share/man/man1/python3.1.gz
> > >
> > > We going to lean on 3.7 here going forward, so I think that's
where
> > > our focus should be for this MET install. So, using a full
pathname
> > > to identify the cflags and ldflags associated with python3.7
returns
> > > the
> > > following:
> > >
> > >
> > > >/usr/local/bin/python3.7m-config --cflags
> > > -I/usr/local/include/python3.7m -I/usr/local/include/python3.7m
> > > -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
> > >
> > > /usr/local/bin/python3.7m-config --ldflags
> > > -L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -L/usr/local/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
> > >
> > >
> > > Using this information, we had a breakthrough! It turns out, I
had
> > > the full pathname listed for the ldflag, and I shouldn't have.
> > > Replacing that with simply -lpython3.7m was successful for the
> > > configure
> > >
> > > Simple, silly problem--but our unorthodox structure of python on
> > > this machine lead to some confusion on my end.
> > >
> > > HOWEVER--the make install has failed, and this appears to do
with
> > > python3.7. Of course it does, right?? I've included the
> > > make_install.log file for reference. Normally I would spend
time
> > > hacking at this to see if I could figure it out without
bothering
> > > you, but I'm not familiar at all with where this error may be
coming
> from. Any ideas??
> > >
> > > /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> > > undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> > > //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
> > > command line
> > > collect2: error: ld returned 1 exit status
> > > make[4]: *** [ensemble_stat] Error 1
> > > make[4]: Leaving directory
> > > `/fewxops/software/met/met-9.1/src/tools/core/ensemble_stat'
> > > make[3]: *** [install-recursive] Error 1
> > > make[3]: Leaving directory
> `/fewxops/software/met/met-9.1/src/tools/core'
> > > make[2]: *** [install-recursive] Error 1
> > > make[2]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools'
> > > make[1]: *** [install-recursive] Error 1
> > > make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
> > >
> > > make: *** [install-recursive] Error 1
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > > Sent: Monday, September 14, 2020 12:39 PM
> > > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > > -- upgrade to MET 9.1 from 8.1.2
> > >
> > > Hi Tom.
> > >
> > > Thank you for the additional information and for your new
config.log
> file.
> > > It looks like Python is still having trouble:
> > >
> > > /usr/bin/ld: cannot find -l/usr/local/include/python3.7m
> > > >
> > > > collect2: error: ld returned 1 exit status
> > > >
> > >
> > > I have a feeling the python arrangement on this system could be
> > > where the
> > > > problem is.
> > > >
> > > That could very well be. Let's see what we can figure out and
try
> > > to get it set up correctly, assuming the Python arrangement is
ok on
> your system.
> > >
> > > Do you know where the python3 executable lives? Perhaps in
> > > /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping
the
> > > "python3-config" executable will be in the same directory and
that
> > > you received "python3-config: Command not found." because it was
> > > just not in your path. Being able to run "python3-config
--cflags"
> > > and "python3-config --ldflags" will help us know what we should
set
> > > MET_PYTHON_CC and MET_PYTHON_LD flags to.
> > >
> > > For the record, Python.h does exist in
/usr/local/include/python3.7m
> > > >
> > > Hrm. If you run "find /usr/local/ -name Python.h", can you find
it?
> > >
> > > Currently, these are how my python environmental variables are
> > > defined in
> > > > the .cshrc:
> > >
> > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > > setenv MET_PYTHON_LD
> > > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -lpython-config.py'
> > > > Perhaps I’m routing that incorrectly?
> > >
> > > Typically we wouldn't have "-lpython-config.py", but rather
> > > "-lpython3.7m". There would also typically be other libraries
to
> > > link with as well and sometimes another path as well. Here are
some
> > > examples from two different machines:
> > >
> > > setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\
-lcrypt\
> > > > -lpthread\ -ldl\ -lutil\ -lm
> > >
> > >
> > > and
> > >
> > > export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
> > > -lpython3.6m\
> > > > -lpthread\ -ldl\ -lutil\ -lrt\ -lm
> > >
> > >
> > >
> > > But given we’ll be leaning on METplus heavily going forward, I
> > > wanted to
> > > > figure this out with the installation of 9.1.
> > >
> > > We're so glad to hear that you will be using METplus heavily. I
> > > hope we can get the Python embedding functionality working for
you.
> > > It's such a great tool to have. We're happy to help with
whatever
> > > you need with regard to METplus, so please let us know.
> > >
> > > Julie
> > >
> > > On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693
>
> > > >
> > > > Good Morning Julie,
> > > >
> > > > Thanks for the quick response.
> > > >
> > > > I have a feeling the python arrangement on this system could
be
> > > > where the problem is. Given it's an older redhat build (that
part
> > > > I can't get around, per IT), python2.7 is the one that's
> > > > linked/seen by the system. We have python3.7 installed, but a
> > > > simple command for the
> > > > python3 config doesn't work:
> > > >
> > > > ----------------------------------
> > > > python3-config -ldflags
> > > > python3-config: Command not found.
> > > >
> > > > python3.7-config -ldflags
> > > > python3.7-config: Command not found.
> > > > -------------------------------------------------
> > > >
> > > > Currently, these are how my python environmental variables are
> > > > defined in the .cshrc:
> > > >
> > > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > > setenv MET_PYTHON_LD
> > > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -lpython-config.py'
> > > >
> > > > Perhaps I’m routing that incorrectly?
> > > >
> > > > For reference, here is the listing of the
> > > > /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
Directory;
> > > > -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> > > > -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> > > > -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> > > > -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> > > > -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> > > > -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> > > > -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> > > > -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> > > > -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> > > > -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
> > > >
> > > > For the record, Python.h does exist in
> > > > /usr/local/include/python3.7m
> > > >
> > > > I realized I had a typo in the filepath for MET_PYTHON_LD the
> > > > first time, but fixing that hasn’t helped the problem. The
new
> > > > log file is
> > > attached.
> > > >
> > > > I a problem linking python3.7 with the 8.1.2 installation….but
let
> > > > it compile with 2.7 since I wasn’t using python for anything
> > > > taxing at the time. But given we’ll be leaning on METplus
heavily
> > > > going forward, I wanted to figure this out with the
installation of
> 9.1.
> > > >
> > > > Thanks for looking this over!
> > > >
> > >
> > > --
> > > Julie Prestopnik (she/her/hers)
> > > Software Engineer
> > > National Center for Atmospheric Research Research Applications
> > > Laboratory
> > > Phone: 303.497.8399
> > > Email: jpresto at ucar.edu
> > >
> > > My working day may not be your working day. Please do not feel
> > > obliged to reply to this email outside of your normal working
hours.
> > >
> > >
> > >
--------------------------------------------------------------------
> > > --
> > > --------
> > >
> > > The information contained in this message is intended only for
the
> > > personal and confidential use of the recipient(s) named above.
If
> > > the reader of this message is not the intended recipient or an
agent
> > > responsible for delivering it to the intended recipient, you are
> > > hereby notified that you have received this document in error
and
> > > that any review, dissemination, distribution, or copying of this
> > > message is strictly prohibited. If you have received this
> > > communication in error, please notify us immediately, and delete
the
> original message.
> > >
> > >
> >
> > --
> > Julie Prestopnik (she/her/hers)
> > Software Engineer
> > National Center for Atmospheric Research Research Applications
> > Laboratory
> > Phone: 303.497.8399
> > Email: jpresto at ucar.edu
> >
> > My working day may not be your working day. Please do not feel
obliged
> to reply to this email outside of your normal working hours.
> >
> >
----------------------------------------------------------------------
> > --------
> >
> > The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
hereby
> notified that you have received this document in error and that any
review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately, and delete the original message.
> >
>
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research Research Applications
Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
obliged to
> reply to this email outside of your normal working hours.
>
>
>
>
------------------------------------------------------------------------------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
hereby
> notified that you have received this document in error and that any
review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately, and delete the original message.
>
>
>
------------------------------------------------
Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error -- upgrade to MET 9.1 from 8.1.2
From: Workoff, Thomas E
Time: Fri Sep 18 06:14:54 2020
Thanks, Minna!
This will be very helpful. I believe METViewer will provide a lot of
basic functionality that's needed, but it's nice to have access to the
background scripts for any additional development and plotting needs.
I'm also happy to hear about the switch from R to Python! If I
develop anything new along the way over the next several months, I
will pass it along. I doubt I'll write anything sharp enough to help
the community, but stranger things have happened!
Thanks again,
Thomas Workoff
Senior Scientist
Office: 330-436-1475 (850-1475)
tworkoff at firstenergycorp.com
341 White Pond Drive, Akron, OH 44320 | mailstop: A-WAC-C1 / AK-West
Akron Campus
-----Original Message-----
From: Minna Win via RT <met_help at ucar.edu>
Sent: Thursday, September 17, 2020 11:58 AM
To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
-- upgrade to MET 9.1 from 8.1.2
Hi Tom,
The R scripts that are currently available for viewing MET output are
located in the MET repository:
https://github.com/dtcenter/MET/tree/master_v9.1/met/scripts/Rscripts
We are currently working on replacing the R scripts (with python) that
are
currently used in METviewer. The code under construction can be
found in
the METplotpy repository: https://github.com/dtcenter/METplotpy. We
have a scheduled 1.0 release in March 2021. Our documentation is not
as mature (and in some instances non-existent at this point) as the
MET and METplus wrappers documentation. Hopefully you can find some
of the existing code to be useful. If you make any modifications or
have any novel plotting scripts, we'd welcome any contribution. Some
of the plots are implemented in matplotlib. We are striving to have
the plots implemented in python plotly for interactivity (whenever
possible).
I hope that helps answer your question.
Regards,
Minna
---------------
Minna Win
National Center for Atmospheric Research Developmental Testbed Center
Phone: 303-497-8423
Fax: 303-497-8401
On Thu, Sep 17, 2020 at 8:06 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Julie--
>
> Success! (I think).
>
> The updated python LD reference did the trick. I reconfigured and
> installed with simply python and mode graphics activated, and things
> appear to have run smoothly. I then backtracked and added grib2
> functionality, and still appear to be successful.
>
> I really appreciate all your help on this!
>
> I'll now work through making the adjustments needed to run 9.1 from
8.1.2.
>
> On an unrelated note: does there happen to be a script repository or
> references available for the plotting of MET output data (such as
the
> plots shown in chapter 25 of the User's Manual)? I can put together
> plots myself via python or R, but I'm just wondering if there's
> something available in the community to help streamline that
process.
>
> On a second semi-related note: it does appear my original email was
sent.
> I was wondering if, with all the VPN and working remotely drama, if
> perhaps my email got stuck in my outbox and was never actually sent
to
> you. But, it appears it was indeed sent out. So, it may be one of
> the big mysteries of the universe as to how it never made it to you!
> Regardless, I appreciate you working through all the issues with me.
>
> Thanks!
> -Tom
>
>
>
>
>
> -----Original Message-----
> From: Julie Prestopnik via RT <met_help at ucar.edu>
> Sent: Wednesday, September 16, 2020 3:17 PM
> To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
> -- upgrade to MET 9.1 from 8.1.2
>
> Thank you for all of this information!
>
> I see that you are getting a linker error related to python when
> compiling
> MET:
>
> /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
command
> line
>
> Let's have you try setting MET_PYTHON_LD to
>
> export
> MET_PYTHON_LD=-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-
gnu\
> -L/usr/local/lib\ -lpython3.7m\ -lcrypt\ -lpthread\ -ldl\ -lutil\
-lm
>
> Let's also have you try reconfiguring and compiling without the
> “—enable-grib2” option. Let’s make sure there’s no other issues
> waiting to be found. Once that successfully compiles we can circle
> back and debug the
> GRIB2 problems.
>
> Please let me know how it goes. I'm also a little concerned about
not
> having received that other email from you. So, if you respond and I
> don't respond within 24 hours, please send me another message to
follow up.
>
> Thanks!
>
> Julie
>
> On Tue, Sep 15, 2020 at 12:00 PM Workoff, Thomas E via RT <
> met_help at ucar.edu> wrote:
> >
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> >
> > Sure thing, it's attached!
> >
> > If there ends up being any other supporting information you need
> (environmental variables, etc), just let me know.
> >
> > I appreciate your help. No rush!
> >
> >
> > -----Original Message-----
> > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > Sent: Tuesday, September 15, 2020 1:52 PM
> > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > -- upgrade to MET 9.1 from 8.1.2
> >
> > Hi Tom.
> >
> > I'm so glad you responded with the config.log file. Could you
> > please
> resend the make.log file as well? Unfortunately, I never received
the
> email that you are replying to (that you sent yesterday at 1:16pm.
If
> you hadn't this email I wouldn't have known that you responded.
> >
> > Please send over that make.log file when you get a chance. I have
> meetings for the rest of the day, but hope to take a look at this
> tomorrow morning.
> > I'll follow up as soon as I can.
> >
> > Julie
> >
> > On Tue, Sep 15, 2020 at 11:43 AM Workoff, Thomas E via RT
> > <met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> > >
> > > Hi Julie,
> > >
> > > Realized this morning that I should have sent over the
config.log
> > > file for the *apparently* successful configure process, along
with
> > > the make_install.log file.
> > >
> > > It is attached.
> > >
> > > Thanks!
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Workoff, Thomas E
> > > Sent: Monday, September 14, 2020 1:16 PM
> > > To: met_help at ucar.edu
> > > Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
> > > error
> > > -- upgrade to MET 9.1 from 8.1.2
> > >
> > > Julie...
> > >
> > >
> > > Ahhhhhhh Ha! I think we're making progress here. Searching for
> > > python3 gave me a few options on this system:
> > >
> > >
> > > > whereis python3
> > > > python3: /usr/bin/python3.6m /usr/bin/python3.6
/usr/bin/python3
> > > > /usr/lib/python3.6 /usr/lib64/python3.6
/usr/local/bin/python3.7
> > > > /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> > > > /usr/local/lib/python3.7 /usr/include/python3.6m
> > > > /usr/share/man/man1/python3.1.gz
> > >
> > > We going to lean on 3.7 here going forward, so I think that's
> > > where our focus should be for this MET install. So, using a
full
> > > pathname to identify the cflags and ldflags associated with
> > > python3.7 returns the
> > > following:
> > >
> > >
> > > >/usr/local/bin/python3.7m-config --cflags
> > > -I/usr/local/include/python3.7m -I/usr/local/include/python3.7m
> > > -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
> > >
> > > /usr/local/bin/python3.7m-config --ldflags
> > > -L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -L/usr/local/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
> > >
> > >
> > > Using this information, we had a breakthrough! It turns out, I
had
> > > the full pathname listed for the ldflag, and I shouldn't have.
> > > Replacing that with simply -lpython3.7m was successful for the
> > > configure
> > >
> > > Simple, silly problem--but our unorthodox structure of python on
> > > this machine lead to some confusion on my end.
> > >
> > > HOWEVER--the make install has failed, and this appears to do
with
> > > python3.7. Of course it does, right?? I've included the
> > > make_install.log file for reference. Normally I would spend
time
> > > hacking at this to see if I could figure it out without
bothering
> > > you, but I'm not familiar at all with where this error may be
> > > coming
> from. Any ideas??
> > >
> > > /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> > > undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> > > //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
> > > command line
> > > collect2: error: ld returned 1 exit status
> > > make[4]: *** [ensemble_stat] Error 1
> > > make[4]: Leaving directory
> > > `/fewxops/software/met/met-9.1/src/tools/core/ensemble_stat'
> > > make[3]: *** [install-recursive] Error 1
> > > make[3]: Leaving directory
> `/fewxops/software/met/met-9.1/src/tools/core'
> > > make[2]: *** [install-recursive] Error 1
> > > make[2]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools'
> > > make[1]: *** [install-recursive] Error 1
> > > make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
> > >
> > > make: *** [install-recursive] Error 1
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > > Sent: Monday, September 14, 2020 12:39 PM
> > > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
> > > error
> > > -- upgrade to MET 9.1 from 8.1.2
> > >
> > > Hi Tom.
> > >
> > > Thank you for the additional information and for your new
> > > config.log
> file.
> > > It looks like Python is still having trouble:
> > >
> > > /usr/bin/ld: cannot find -l/usr/local/include/python3.7m
> > > >
> > > > collect2: error: ld returned 1 exit status
> > > >
> > >
> > > I have a feeling the python arrangement on this system could be
> > > where the
> > > > problem is.
> > > >
> > > That could very well be. Let's see what we can figure out and
try
> > > to get it set up correctly, assuming the Python arrangement is
ok
> > > on
> your system.
> > >
> > > Do you know where the python3 executable lives? Perhaps in
> > > /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping
the
> > > "python3-config" executable will be in the same directory and
that
> > > you received "python3-config: Command not found." because it was
> > > just not in your path. Being able to run "python3-config
--cflags"
> > > and "python3-config --ldflags" will help us know what we should
> > > set MET_PYTHON_CC and MET_PYTHON_LD flags to.
> > >
> > > For the record, Python.h does exist in
> > > /usr/local/include/python3.7m
> > > >
> > > Hrm. If you run "find /usr/local/ -name Python.h", can you find
it?
> > >
> > > Currently, these are how my python environmental variables are
> > > defined in
> > > > the .cshrc:
> > >
> > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > > setenv MET_PYTHON_LD
> > > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -lpython-config.py'
> > > > Perhaps I’m routing that incorrectly?
> > >
> > > Typically we wouldn't have "-lpython-config.py", but rather
> > > "-lpython3.7m". There would also typically be other libraries
to
> > > link with as well and sometimes another path as well. Here are
> > > some examples from two different machines:
> > >
> > > setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\
> > > -lcrypt\
> > > > -lpthread\ -ldl\ -lutil\ -lm
> > >
> > >
> > > and
> > >
> > > export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
> > > -lpython3.6m\
> > > > -lpthread\ -ldl\ -lutil\ -lrt\ -lm
> > >
> > >
> > >
> > > But given we’ll be leaning on METplus heavily going forward, I
> > > wanted to
> > > > figure this out with the installation of 9.1.
> > >
> > > We're so glad to hear that you will be using METplus heavily. I
> > > hope we can get the Python embedding functionality working for
you.
> > > It's such a great tool to have. We're happy to help with
whatever
> > > you need with regard to METplus, so please let us know.
> > >
> > > Julie
> > >
> > > On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT <
> > > met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693
>
> > > >
> > > > Good Morning Julie,
> > > >
> > > > Thanks for the quick response.
> > > >
> > > > I have a feeling the python arrangement on this system could
be
> > > > where the problem is. Given it's an older redhat build (that
> > > > part I can't get around, per IT), python2.7 is the one that's
> > > > linked/seen by the system. We have python3.7 installed, but a
> > > > simple command for the
> > > > python3 config doesn't work:
> > > >
> > > > ----------------------------------
> > > > python3-config -ldflags
> > > > python3-config: Command not found.
> > > >
> > > > python3.7-config -ldflags
> > > > python3.7-config: Command not found.
> > > > -------------------------------------------------
> > > >
> > > > Currently, these are how my python environmental variables are
> > > > defined in the .cshrc:
> > > >
> > > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > > setenv MET_PYTHON_LD
> > > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > -lpython-config.py'
> > > >
> > > > Perhaps I’m routing that incorrectly?
> > > >
> > > > For reference, here is the listing of the
> > > > /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
Directory;
> > > > -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> > > > -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> > > > -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> > > > -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> > > > -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> > > > -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> > > > -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-config.py
> > > > -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> > > > -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> > > > -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
> > > >
> > > > For the record, Python.h does exist in
> > > > /usr/local/include/python3.7m
> > > >
> > > > I realized I had a typo in the filepath for MET_PYTHON_LD the
> > > > first time, but fixing that hasn’t helped the problem. The
new
> > > > log file is
> > > attached.
> > > >
> > > > I a problem linking python3.7 with the 8.1.2 installation….but
> > > > let it compile with 2.7 since I wasn’t using python for
anything
> > > > taxing at the time. But given we’ll be leaning on METplus
> > > > heavily going forward, I wanted to figure this out with the
> > > > installation of
> 9.1.
> > > >
> > > > Thanks for looking this over!
> > > >
> > >
> > > --
> > > Julie Prestopnik (she/her/hers)
> > > Software Engineer
> > > National Center for Atmospheric Research Research Applications
> > > Laboratory
> > > Phone: 303.497.8399
> > > Email: jpresto at ucar.edu
> > >
> > > My working day may not be your working day. Please do not feel
> > > obliged to reply to this email outside of your normal working
hours.
> > >
> > >
> > >
------------------------------------------------------------------
> > > --
> > > --
> > > --------
> > >
> > > The information contained in this message is intended only for
the
> > > personal and confidential use of the recipient(s) named above.
If
> > > the reader of this message is not the intended recipient or an
> > > agent responsible for delivering it to the intended recipient,
you
> > > are hereby notified that you have received this document in
error
> > > and that any review, dissemination, distribution, or copying of
> > > this message is strictly prohibited. If you have received this
> > > communication in error, please notify us immediately, and delete
> > > the
> original message.
> > >
> > >
> >
> > --
> > Julie Prestopnik (she/her/hers)
> > Software Engineer
> > National Center for Atmospheric Research Research Applications
> > Laboratory
> > Phone: 303.497.8399
> > Email: jpresto at ucar.edu
> >
> > My working day may not be your working day. Please do not feel
> > obliged
> to reply to this email outside of your normal working hours.
> >
> >
--------------------------------------------------------------------
> > --
> > --------
> >
> > The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
> hereby notified that you have received this document in error and
that
> any review, dissemination, distribution, or copying of this message
is
> strictly prohibited. If you have received this communication in
error,
> please notify us immediately, and delete the original message.
> >
>
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research Research Applications
> Laboratory
> Phone: 303.497.8399
> Email: jpresto at ucar.edu
>
> My working day may not be your working day. Please do not feel
> obliged to reply to this email outside of your normal working hours.
>
>
>
>
----------------------------------------------------------------------
> --------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
> hereby notified that you have received this document in error and
that
> any review, dissemination, distribution, or copying of this message
is
> strictly prohibited. If you have received this communication in
error,
> please notify us immediately, and delete the original message.
>
>
>
------------------------------------------------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
------------------------------------------------
Subject: Configure error -- upgrade to MET 9.1 from 8.1.2
From: Julie Prestopnik
Time: Fri Sep 18 08:23:20 2020
Hi Tom.
I'm so glad everything is working for you now and that Minna was able
to
provide you with information about plotting. I'm going to go ahead
and
close this ticket. Please feel free to submit a new ticket with any
other
questions that you have.
Julie
On Fri, Sep 18, 2020 at 6:14 AM Workoff, Thomas E via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
>
> Thanks, Minna!
>
> This will be very helpful. I believe METViewer will provide a lot
of
> basic functionality that's needed, but it's nice to have access to
the
> background scripts for any additional development and plotting
needs.
>
> I'm also happy to hear about the switch from R to Python! If I
develop
> anything new along the way over the next several months, I will pass
it
> along. I doubt I'll write anything sharp enough to help the
community, but
> stranger things have happened!
>
> Thanks again,
>
> Thomas Workoff
> Senior Scientist
> Office: 330-436-1475 (850-1475)
> tworkoff at firstenergycorp.com
> 341 White Pond Drive, Akron, OH 44320 | mailstop: A-WAC-C1 / AK-West
Akron
> Campus
>
>
> -----Original Message-----
> From: Minna Win via RT <met_help at ucar.edu>
> Sent: Thursday, September 17, 2020 11:58 AM
> To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure error
--
> upgrade to MET 9.1 from 8.1.2
>
> Hi Tom,
>
> The R scripts that are currently available for viewing MET output
are
> located in the MET repository:
>
https://github.com/dtcenter/MET/tree/master_v9.1/met/scripts/Rscripts
>
> We are currently working on replacing the R scripts (with python)
that are
> currently used in METviewer. The code under construction can be
found in
> the METplotpy repository: https://github.com/dtcenter/METplotpy. We
have
> a scheduled 1.0 release in March 2021. Our documentation is not as
mature
> (and in some instances non-existent at this point) as the MET and
METplus
> wrappers documentation. Hopefully you can find some of the existing
code
> to be useful. If you make any modifications or have any novel
plotting
> scripts, we'd welcome any contribution. Some of the plots are
implemented
> in matplotlib. We are striving to have the plots implemented in
python
> plotly for interactivity (whenever possible).
>
> I hope that helps answer your question.
>
> Regards,
> Minna
>
> ---------------
> Minna Win
> National Center for Atmospheric Research Developmental Testbed
Center
> Phone: 303-497-8423
> Fax: 303-497-8401
>
>
>
> On Thu, Sep 17, 2020 at 8:06 AM Workoff, Thomas E via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> >
> > Julie--
> >
> > Success! (I think).
> >
> > The updated python LD reference did the trick. I reconfigured and
> > installed with simply python and mode graphics activated, and
things
> > appear to have run smoothly. I then backtracked and added grib2
> > functionality, and still appear to be successful.
> >
> > I really appreciate all your help on this!
> >
> > I'll now work through making the adjustments needed to run 9.1
from
> 8.1.2.
> >
> > On an unrelated note: does there happen to be a script repository
or
> > references available for the plotting of MET output data (such as
the
> > plots shown in chapter 25 of the User's Manual)? I can put
together
> > plots myself via python or R, but I'm just wondering if there's
> > something available in the community to help streamline that
process.
> >
> > On a second semi-related note: it does appear my original email
was sent.
> > I was wondering if, with all the VPN and working remotely drama,
if
> > perhaps my email got stuck in my outbox and was never actually
sent to
> > you. But, it appears it was indeed sent out. So, it may be one
of
> > the big mysteries of the universe as to how it never made it to
you!
> > Regardless, I appreciate you working through all the issues with
me.
> >
> > Thanks!
> > -Tom
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > Sent: Wednesday, September 16, 2020 3:17 PM
> > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > -- upgrade to MET 9.1 from 8.1.2
> >
> > Thank you for all of this information!
> >
> > I see that you are getting a linker error related to python when
> > compiling
> > MET:
> >
> > /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> > undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> > //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
command
> > line
> >
> > Let's have you try setting MET_PYTHON_LD to
> >
> > export
> > MET_PYTHON_LD=-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-
gnu\
> > -L/usr/local/lib\ -lpython3.7m\ -lcrypt\ -lpthread\ -ldl\ -lutil\
-lm
> >
> > Let's also have you try reconfiguring and compiling without the
> > “—enable-grib2” option. Let’s make sure there’s no other issues
> > waiting to be found. Once that successfully compiles we can
circle
> > back and debug the
> > GRIB2 problems.
> >
> > Please let me know how it goes. I'm also a little concerned about
not
> > having received that other email from you. So, if you respond and
I
> > don't respond within 24 hours, please send me another message to
follow
> up.
> >
> > Thanks!
> >
> > Julie
> >
> > On Tue, Sep 15, 2020 at 12:00 PM Workoff, Thomas E via RT <
> > met_help at ucar.edu> wrote:
> > >
> > >
> > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> > >
> > > Sure thing, it's attached!
> > >
> > > If there ends up being any other supporting information you need
> > (environmental variables, etc), just let me know.
> > >
> > > I appreciate your help. No rush!
> > >
> > >
> > > -----Original Message-----
> > > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > > Sent: Tuesday, September 15, 2020 1:52 PM
> > > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
error
> > > -- upgrade to MET 9.1 from 8.1.2
> > >
> > > Hi Tom.
> > >
> > > I'm so glad you responded with the config.log file. Could you
> > > please
> > resend the make.log file as well? Unfortunately, I never received
the
> > email that you are replying to (that you sent yesterday at 1:16pm.
If
> > you hadn't this email I wouldn't have known that you responded.
> > >
> > > Please send over that make.log file when you get a chance. I
have
> > meetings for the rest of the day, but hope to take a look at this
> > tomorrow morning.
> > > I'll follow up as soon as I can.
> > >
> > > Julie
> > >
> > > On Tue, Sep 15, 2020 at 11:43 AM Workoff, Thomas E via RT
> > > <met_help at ucar.edu>
> > > wrote:
> > >
> > > >
> > > > <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693
>
> > > >
> > > > Hi Julie,
> > > >
> > > > Realized this morning that I should have sent over the
config.log
> > > > file for the *apparently* successful configure process, along
with
> > > > the make_install.log file.
> > > >
> > > > It is attached.
> > > >
> > > > Thanks!
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Workoff, Thomas E
> > > > Sent: Monday, September 14, 2020 1:16 PM
> > > > To: met_help at ucar.edu
> > > > Subject: RE: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
> > > > error
> > > > -- upgrade to MET 9.1 from 8.1.2
> > > >
> > > > Julie...
> > > >
> > > >
> > > > Ahhhhhhh Ha! I think we're making progress here. Searching
for
> > > > python3 gave me a few options on this system:
> > > >
> > > >
> > > > > whereis python3
> > > > > python3: /usr/bin/python3.6m /usr/bin/python3.6
/usr/bin/python3
> > > > > /usr/lib/python3.6 /usr/lib64/python3.6
/usr/local/bin/python3.7
> > > > > /usr/local/bin/python3.7m /usr/local/bin/python3.7m-config
> > > > > /usr/local/lib/python3.7 /usr/include/python3.6m
> > > > > /usr/share/man/man1/python3.1.gz
> > > >
> > > > We going to lean on 3.7 here going forward, so I think that's
> > > > where our focus should be for this MET install. So, using a
full
> > > > pathname to identify the cflags and ldflags associated with
> > > > python3.7 returns the
> > > > following:
> > > >
> > > >
> > > > >/usr/local/bin/python3.7m-config --cflags
> > > > -I/usr/local/include/python3.7m
-I/usr/local/include/python3.7m
> > > > -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3
-Wall
> > > >
> > > > /usr/local/bin/python3.7m-config --ldflags
> > > > -L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > > -L/usr/local/lib -lpython3.7m -lcrypt -lpthread -ldl -lutil
-lm
> > > >
> > > >
> > > > Using this information, we had a breakthrough! It turns out, I
had
> > > > the full pathname listed for the ldflag, and I shouldn't have.
> > > > Replacing that with simply -lpython3.7m was successful for
the
> > > > configure
> > > >
> > > > Simple, silly problem--but our unorthodox structure of python
on
> > > > this machine lead to some confusion on my end.
> > > >
> > > > HOWEVER--the make install has failed, and this appears to do
with
> > > > python3.7. Of course it does, right?? I've included the
> > > > make_install.log file for reference. Normally I would spend
time
> > > > hacking at this to see if I could figure it out without
bothering
> > > > you, but I'm not familiar at all with where this error may be
> > > > coming
> > from. Any ideas??
> > > >
> > > > /usr/bin/ld: /usr/local/lib/libpython3.7m.a(dynload_shlib.o):
> > > > undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
> > > > //usr/lib64/libdl.so.2: error adding symbols: DSO missing from
> > > > command line
> > > > collect2: error: ld returned 1 exit status
> > > > make[4]: *** [ensemble_stat] Error 1
> > > > make[4]: Leaving directory
> > > > `/fewxops/software/met/met-9.1/src/tools/core/ensemble_stat'
> > > > make[3]: *** [install-recursive] Error 1
> > > > make[3]: Leaving directory
> > `/fewxops/software/met/met-9.1/src/tools/core'
> > > > make[2]: *** [install-recursive] Error 1
> > > > make[2]: Leaving directory `/fewxops/software/met/met-
9.1/src/tools'
> > > > make[1]: *** [install-recursive] Error 1
> > > > make[1]: Leaving directory `/fewxops/software/met/met-9.1/src'
> > > >
> > > > make: *** [install-recursive] Error 1
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Julie Prestopnik via RT <met_help at ucar.edu>
> > > > Sent: Monday, September 14, 2020 12:39 PM
> > > > To: Workoff, Thomas E <tworkoff at firstenergycorp.com>
> > > > Subject: Re: [EXTERNAL] Re: [rt.rap.ucar.edu #96693] Configure
> > > > error
> > > > -- upgrade to MET 9.1 from 8.1.2
> > > >
> > > > Hi Tom.
> > > >
> > > > Thank you for the additional information and for your new
> > > > config.log
> > file.
> > > > It looks like Python is still having trouble:
> > > >
> > > > /usr/bin/ld: cannot find -l/usr/local/include/python3.7m
> > > > >
> > > > > collect2: error: ld returned 1 exit status
> > > > >
> > > >
> > > > I have a feeling the python arrangement on this system could
be
> > > > where the
> > > > > problem is.
> > > > >
> > > > That could very well be. Let's see what we can figure out and
try
> > > > to get it set up correctly, assuming the Python arrangement is
ok
> > > > on
> > your system.
> > > >
> > > > Do you know where the python3 executable lives? Perhaps in
> > > > /usr/local/bin? Or maybe /usr/local/python3/bin? I am hoping
the
> > > > "python3-config" executable will be in the same directory and
that
> > > > you received "python3-config: Command not found." because it
was
> > > > just not in your path. Being able to run "python3-config
--cflags"
> > > > and "python3-config --ldflags" will help us know what we
should
> > > > set MET_PYTHON_CC and MET_PYTHON_LD flags to.
> > > >
> > > > For the record, Python.h does exist in
> > > > /usr/local/include/python3.7m
> > > > >
> > > > Hrm. If you run "find /usr/local/ -name Python.h", can you
find it?
> > > >
> > > > Currently, these are how my python environmental variables are
> > > > defined in
> > > > > the .cshrc:
> > > >
> > > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > > > setenv MET_PYTHON_LD
> > > > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > > -lpython-config.py'
> > > > > Perhaps I’m routing that incorrectly?
> > > >
> > > > Typically we wouldn't have "-lpython-config.py", but rather
> > > > "-lpython3.7m". There would also typically be other libraries
to
> > > > link with as well and sometimes another path as well. Here
are
> > > > some examples from two different machines:
> > > >
> > > > setenv MET_PYTHON_LD /usr/local/python3/lib\ -lpython3.7m\
> > > > -lcrypt\
> > > > > -lpthread\ -ldl\ -lutil\ -lm
> > > >
> > > >
> > > > and
> > > >
> > > > export MET_PYTHON_LD=-L/usrx/local/prod/python/3.6.3/lib\
> > > > -lpython3.6m\
> > > > > -lpthread\ -ldl\ -lutil\ -lrt\ -lm
> > > >
> > > >
> > > >
> > > > But given we’ll be leaning on METplus heavily going forward, I
> > > > wanted to
> > > > > figure this out with the installation of 9.1.
> > > >
> > > > We're so glad to hear that you will be using METplus heavily.
I
> > > > hope we can get the Python embedding functionality working for
you.
> > > > It's such a great tool to have. We're happy to help with
whatever
> > > > you need with regard to METplus, so please let us know.
> > > >
> > > > Julie
> > > >
> > > > On Mon, Sep 14, 2020 at 10:02 AM Workoff, Thomas E via RT <
> > > > met_help at ucar.edu>
> > > > wrote:
> > > >
> > > > >
> > > > > <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96693 >
> > > > >
> > > > > Good Morning Julie,
> > > > >
> > > > > Thanks for the quick response.
> > > > >
> > > > > I have a feeling the python arrangement on this system could
be
> > > > > where the problem is. Given it's an older redhat build
(that
> > > > > part I can't get around, per IT), python2.7 is the one
that's
> > > > > linked/seen by the system. We have python3.7 installed, but
a
> > > > > simple command for the
> > > > > python3 config doesn't work:
> > > > >
> > > > > ----------------------------------
> > > > > python3-config -ldflags
> > > > > python3-config: Command not found.
> > > > >
> > > > > python3.7-config -ldflags
> > > > > python3.7-config: Command not found.
> > > > > -------------------------------------------------
> > > > >
> > > > > Currently, these are how my python environmental variables
are
> > > > > defined in the .cshrc:
> > > > >
> > > > > setenv MET_PYTHON_CC '-I/usr/local/include/python3.7m'
> > > > > setenv MET_PYTHON_LD
> > > > > '-L/usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > > > -lpython-config.py'
> > > > >
> > > > > Perhaps I’m routing that incorrectly?
> > > > >
> > > > > For reference, here is the listing of the
> > > > > /usr/local/lib/python3.7/config-3.7m-x86_64-linux-gnu
Directory;
> > > > > -rwxr-xr-x 1 root root 3367 Feb 3 2020 config.c
> > > > > -rwxr-xr-x 1 root root 1623 Feb 3 2020 config.c.in
> > > > > -rwxr-xr-x 1 root root 7122 Feb 3 2020 install-sh
> > > > > -rwxr-xr-x 1 root root 24845898 Feb 3 2020 libpython3.7m.a
> > > > > -rwxr-xr-x 1 root root 72808 Feb 3 2020 Makefile
> > > > > -rwxr-xr-x 1 root root 7854 Feb 3 2020 makesetup
> > > > > -rwxr-xr-x 1 root root 1935 Feb 3 2020 python-
config.py
> > > > > -rwxr-xr-x 1 root root 6664 Feb 3 2020 python.o
> > > > > -rwxr-xr-x 1 root root 14509 Feb 3 2020 Setup
> > > > > -rwxr-xr-x 1 root root 41 Feb 3 2020 Setup.local
> > > > >
> > > > > For the record, Python.h does exist in
> > > > > /usr/local/include/python3.7m
> > > > >
> > > > > I realized I had a typo in the filepath for MET_PYTHON_LD
the
> > > > > first time, but fixing that hasn’t helped the problem. The
new
> > > > > log file is
> > > > attached.
> > > > >
> > > > > I a problem linking python3.7 with the 8.1.2
installation….but
> > > > > let it compile with 2.7 since I wasn’t using python for
anything
> > > > > taxing at the time. But given we’ll be leaning on METplus
> > > > > heavily going forward, I wanted to figure this out with the
> > > > > installation of
> > 9.1.
> > > > >
> > > > > Thanks for looking this over!
> > > > >
> > > >
> > > > --
> > > > Julie Prestopnik (she/her/hers)
> > > > Software Engineer
> > > > National Center for Atmospheric Research Research Applications
> > > > Laboratory
> > > > Phone: 303.497.8399
> > > > Email: jpresto at ucar.edu
> > > >
> > > > My working day may not be your working day. Please do not
feel
> > > > obliged to reply to this email outside of your normal working
hours.
> > > >
> > > >
> > > >
------------------------------------------------------------------
> > > > --
> > > > --
> > > > --------
> > > >
> > > > The information contained in this message is intended only for
the
> > > > personal and confidential use of the recipient(s) named above.
If
> > > > the reader of this message is not the intended recipient or an
> > > > agent responsible for delivering it to the intended recipient,
you
> > > > are hereby notified that you have received this document in
error
> > > > and that any review, dissemination, distribution, or copying
of
> > > > this message is strictly prohibited. If you have received this
> > > > communication in error, please notify us immediately, and
delete
> > > > the
> > original message.
> > > >
> > > >
> > >
> > > --
> > > Julie Prestopnik (she/her/hers)
> > > Software Engineer
> > > National Center for Atmospheric Research Research Applications
> > > Laboratory
> > > Phone: 303.497.8399
> > > Email: jpresto at ucar.edu
> > >
> > > My working day may not be your working day. Please do not feel
> > > obliged
> > to reply to this email outside of your normal working hours.
> > >
> > >
--------------------------------------------------------------------
> > > --
> > > --------
> > >
> > > The information contained in this message is intended only for
the
> > personal and confidential use of the recipient(s) named above. If
the
> > reader of this message is not the intended recipient or an agent
> > responsible for delivering it to the intended recipient, you are
> > hereby notified that you have received this document in error and
that
> > any review, dissemination, distribution, or copying of this
message is
> > strictly prohibited. If you have received this communication in
error,
> > please notify us immediately, and delete the original message.
> > >
> >
> >
> > --
> > Julie Prestopnik (she/her/hers)
> > Software Engineer
> > National Center for Atmospheric Research Research Applications
> > Laboratory
> > Phone: 303.497.8399
> > Email: jpresto at ucar.edu
> >
> > My working day may not be your working day. Please do not feel
> > obliged to reply to this email outside of your normal working
hours.
> >
> >
> >
> >
----------------------------------------------------------------------
> > --------
> >
> > The information contained in this message is intended only for the
> > personal and confidential use of the recipient(s) named above. If
the
> > reader of this message is not the intended recipient or an agent
> > responsible for delivering it to the intended recipient, you are
> > hereby notified that you have received this document in error and
that
> > any review, dissemination, distribution, or copying of this
message is
> > strictly prohibited. If you have received this communication in
error,
> > please notify us immediately, and delete the original message.
> >
> >
> >
>
>
>
------------------------------------------------------------------------------
>
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are
hereby
> notified that you have received this document in error and that any
review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
notify
> us immediately, and delete the original message.
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
Phone: 303.497.8399
Email: jpresto at ucar.edu
My working day may not be your working day. Please do not feel
obliged to
reply to this email outside of your normal working hours.
------------------------------------------------
More information about the Met_help
mailing list