[Met_help] [rt.rap.ucar.edu #96902] History for errors in compiling met9.1
Julie Prestopnik via RT
met_help at ucar.edu
Thu Oct 1 09:01:57 MDT 2020
----------------------------------------------------------------
Initial Request
----------------------------------------------------------------
Hello,
I’m running into some errors with compiling met 9.1 on a new Linux machine. I’m using the method described here, with the compile_MET_all.sh script and so forth.
The external libraries compile fine, but when it gets to beginning the process of compiling MET, the “configure” fails. The error in configure.log is:
checking whether the C++ compiler works... no
configure: error: in `/home/rschumac/sources/met-9.1/met-9.1':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
What’s a bit puzzling is that if I *don’t* set the MET_PYTHON, MET_PYTHON_LD, and MET_PYTHON_CC variables, then configure does work, but the rest of the compile fails (because various makefiles are trying to point to the python files but can’t find them).
>From a quick look in the MET email list archives, it appears I’m not the first to have a similar problem, but I can’t identify what the actual solution is. I’ve tried with both gnu and pgi compilers and get the same issue.
Any help would be welcome. Thanks much!
Russ
—
Russ S. Schumacher
Director, Colorado Climate Center
Colorado State Climatologist
Associate Professor, Department of Atmospheric Science
Colorado State University
e-mail: russ.schumacher at colostate.edu<mailto:russ.schumacher at colostate.edu>
phone: 970.491.8084
web: https://www.atmos.colostate.edu/people/faculty/schumacher/
----------------------------------------------------------------
Complete Ticket History
----------------------------------------------------------------
Subject: errors in compiling met9.1
From: George McCabe
Time: Wed Sep 30 13:24:01 2020
Hi Russ,
I see you are having issues compiling MET. I assigned this ticket to
Julie
Prestopnik who is familiar with compiling issues. Please allow a few
business days for a response.
Thanks,
George
On Wed, Sep 30, 2020 at 1:09 PM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> Wed Sep 30 13:07:12 2020: Request 96902 was acted upon.
> Transaction: Ticket created by russ.schumacher at colostate.edu
> Queue: met_help
> Subject: errors in compiling met9.1
> Owner: Nobody
> Requestors: russ.schumacher at colostate.edu
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96902 >
>
>
> Hello,
>
> I’m running into some errors with compiling met 9.1 on a new Linux
> machine. I’m using the method described here, with the
compile_MET_all.sh
> script and so forth.
>
> The external libraries compile fine, but when it gets to beginning
the
> process of compiling MET, the “configure” fails. The error in
> configure.log is:
> checking whether the C++ compiler works... no
> configure: error: in `/home/rschumac/sources/met-9.1/met-9.1':
> configure: error: C++ compiler cannot create executables
> See `config.log' for more details
>
> What’s a bit puzzling is that if I *don’t* set the MET_PYTHON,
> MET_PYTHON_LD, and MET_PYTHON_CC variables, then configure does
work, but
> the rest of the compile fails (because various makefiles are trying
to
> point to the python files but can’t find them).
>
> From a quick look in the MET email list archives, it appears I’m not
the
> first to have a similar problem, but I can’t identify what the
actual
> solution is. I’ve tried with both gnu and pgi compilers and get the
same
> issue.
>
> Any help would be welcome. Thanks much!
>
> Russ
>
>
>
>
>
> —
> Russ S. Schumacher
> Director, Colorado Climate Center
> Colorado State Climatologist
> Associate Professor, Department of Atmospheric Science
> Colorado State University
> e-mail:
russ.schumacher at colostate.edu<mailto:russ.schumacher at colostate.edu
> >
> phone: 970.491.8084
> web: https://www.atmos.colostate.edu/people/faculty/schumacher/
>
>
>
--
George McCabe - Software Engineer III
National Center for Atmospheric Research
Research Applications Laboratory
303-497-2768
---
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: errors in compiling met9.1
From: Julie Prestopnik
Time: Wed Sep 30 15:25:41 2020
Hi Russ.
I see that you are having problems compiling MET. If it's ok with
you,
let's try to work through this using the GNU compiler. Could you
please
send me your configuration file for the compile_MET_all.sh script and
also
the config.log file in the met-9.1 directory from when you do have the
MET_PYTHON, MET_PYTHON_LD, and MET_PYTHON_CC variables set and are
using
the GNU compiler?
Thank you!
Julie
On Wed, Sep 30, 2020 at 1:09 PM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> Wed Sep 30 13:07:12 2020: Request 96902 was acted upon.
> Transaction: Ticket created by russ.schumacher at colostate.edu
> Queue: met_help
> Subject: errors in compiling met9.1
> Owner: Nobody
> Requestors: russ.schumacher at colostate.edu
> Status: new
> Ticket <URL:
https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96902 >
>
>
> Hello,
>
> I’m running into some errors with compiling met 9.1 on a new Linux
> machine. I’m using the method described here, with the
compile_MET_all.sh
> script and so forth.
>
> The external libraries compile fine, but when it gets to beginning
the
> process of compiling MET, the “configure” fails. The error in
> configure.log is:
> checking whether the C++ compiler works... no
> configure: error: in `/home/rschumac/sources/met-9.1/met-9.1':
> configure: error: C++ compiler cannot create executables
> See `config.log' for more details
>
> What’s a bit puzzling is that if I *don’t* set the MET_PYTHON,
> MET_PYTHON_LD, and MET_PYTHON_CC variables, then configure does
work, but
> the rest of the compile fails (because various makefiles are trying
to
> point to the python files but can’t find them).
>
> From a quick look in the MET email list archives, it appears I’m not
the
> first to have a similar problem, but I can’t identify what the
actual
> solution is. I’ve tried with both gnu and pgi compilers and get the
same
> issue.
>
> Any help would be welcome. Thanks much!
>
> Russ
>
>
>
>
>
> —
> Russ S. Schumacher
> Director, Colorado Climate Center
> Colorado State Climatologist
> Associate Professor, Department of Atmospheric Science
> Colorado State University
> e-mail:
russ.schumacher at colostate.edu<mailto:russ.schumacher at colostate.edu
> >
> phone: 970.491.8084
> web: https://www.atmos.colostate.edu/people/faculty/schumacher/
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
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: errors in compiling met9.1
From: Russ Schumacher
Time: Wed Sep 30 17:06:59 2020
Hi Julie,
Here are those files - let me know if there are additional details I
can provide. Thanks!
Russ
On 9/30/20, 3:25 PM, "Julie Prestopnik via RT" <met_help at ucar.edu>
wrote:
Hi Russ.
I see that you are having problems compiling MET. If it's ok with
you,
let's try to work through this using the GNU compiler. Could you
please
send me your configuration file for the compile_MET_all.sh script
and also
the config.log file in the met-9.1 directory from when you do have
the
MET_PYTHON, MET_PYTHON_LD, and MET_PYTHON_CC variables set and are
using
the GNU compiler?
Thank you!
Julie
On Wed, Sep 30, 2020 at 1:09 PM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> Wed Sep 30 13:07:12 2020: Request 96902 was acted upon.
> Transaction: Ticket created by russ.schumacher at colostate.edu
> Queue: met_help
> Subject: errors in compiling met9.1
> Owner: Nobody
> Requestors: russ.schumacher at colostate.edu
> Status: new
> Ticket <URL:
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D96902&data=02%7C01%7Cruss.schumacher%40colostate.edu%7Ca2eea519f7a541d8ec2e08d865876352%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637370979455964750&sdata=2QpQXfy7wklkcmEhquqE7%2BTdxAey2nW8B1SMARbbdX8%3D&reserved=0
>
>
>
> Hello,
>
> I’m running into some errors with compiling met 9.1 on a new
Linux
> machine. I’m using the method described here, with the
compile_MET_all.sh
> script and so forth.
>
> The external libraries compile fine, but when it gets to
beginning the
> process of compiling MET, the “configure” fails. The error in
> configure.log is:
> checking whether the C++ compiler works... no
> configure: error: in `/home/rschumac/sources/met-9.1/met-9.1':
> configure: error: C++ compiler cannot create executables
> See `config.log' for more details
>
> What’s a bit puzzling is that if I *don’t* set the MET_PYTHON,
> MET_PYTHON_LD, and MET_PYTHON_CC variables, then configure does
work, but
> the rest of the compile fails (because various makefiles are
trying to
> point to the python files but can’t find them).
>
> From a quick look in the MET email list archives, it appears I’m
not the
> first to have a similar problem, but I can’t identify what the
actual
> solution is. I’ve tried with both gnu and pgi compilers and get
the same
> issue.
>
> Any help would be welcome. Thanks much!
>
> Russ
>
>
>
>
>
> —
> Russ S. Schumacher
> Director, Colorado Climate Center
> Colorado State Climatologist
> Associate Professor, Department of Atmospheric Science
> Colorado State University
> e-mail:
russ.schumacher at colostate.edu<mailto:russ.schumacher at colostate.edu
> >
> phone: 970.491.8084
> web: https://www.atmos.colostate.edu/people/faculty/schumacher/
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
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: errors in compiling met9.1
From: Julie Prestopnik
Time: Wed Sep 30 17:59:13 2020
Hi Russ.
Thanks so much for sending the files. They are very useful.
Did you happen to run the command "python3-config --ldflags" to get
the
value for MET_PYTHON_LD? If not, please run that command and let me
know
what it returns. If so, it is unfortunate, because it is not telling
us
the location of the Python library file, which we need for MET. Since
the
include file is in "/usr/include/python3.7m", I can look at a similar
structure on one of our machines and see the library file here:
> find /usr/lib/python3.5 -name "*libpython*"
>
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5.so
>
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m.so
>
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m.a
>
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m-pic.a
>
So, perhaps your library file is in a similar directory, in which case
you
would try setting MET_PYTHON_LD in the following way:
export MET_PYTHON_LD=-L/usr/lib/python3.7/config-3.7m-x86_64-linux-
gnu\
> -lpython3.7\ -lcrypt\ -lpthread\ -ldl\ -lutil\ -lm\ -Xlinker\
> -export-dynamic
>
Please note the addition of the "-L" followed by the path and also the
removal of the quotation marks around the value.
Give that a shot and let us know how it goes. If it still does not
compile, please send your new config.log file. Thanks!
Julie
On Wed, Sep 30, 2020 at 5:10 PM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96902 >
>
> Hi Julie,
>
> Here are those files - let me know if there are additional details I
can
> provide. Thanks!
>
> Russ
>
>
>
>
> On 9/30/20, 3:25 PM, "Julie Prestopnik via RT" <met_help at ucar.edu>
wrote:
>
> Hi Russ.
>
> I see that you are having problems compiling MET. If it's ok
with you,
> let's try to work through this using the GNU compiler. Could
you
> please
> send me your configuration file for the compile_MET_all.sh
script and
> also
> the config.log file in the met-9.1 directory from when you do
have the
> MET_PYTHON, MET_PYTHON_LD, and MET_PYTHON_CC variables set and
are
> using
> the GNU compiler?
>
> Thank you!
>
> Julie
>
> On Wed, Sep 30, 2020 at 1:09 PM Russ Schumacher via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > Wed Sep 30 13:07:12 2020: Request 96902 was acted upon.
> > Transaction: Ticket created by russ.schumacher at colostate.edu
> > Queue: met_help
> > Subject: errors in compiling met9.1
> > Owner: Nobody
> > Requestors: russ.schumacher at colostate.edu
> > Status: new
> > Ticket <URL:
>
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D96902&data=02%7C01%7Cruss.schumacher%40colostate.edu%7Ca2eea519f7a541d8ec2e08d865876352%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637370979455964750&sdata=2QpQXfy7wklkcmEhquqE7%2BTdxAey2nW8B1SMARbbdX8%3D&reserved=0
> >
> >
> >
> > Hello,
> >
> > I’m running into some errors with compiling met 9.1 on a new
Linux
> > machine. I’m using the method described here, with the
> compile_MET_all.sh
> > script and so forth.
> >
> > The external libraries compile fine, but when it gets to
beginning
> the
> > process of compiling MET, the “configure” fails. The error in
> > configure.log is:
> > checking whether the C++ compiler works... no
> > configure: error: in `/home/rschumac/sources/met-9.1/met-9.1':
> > configure: error: C++ compiler cannot create executables
> > See `config.log' for more details
> >
> > What’s a bit puzzling is that if I *don’t* set the MET_PYTHON,
> > MET_PYTHON_LD, and MET_PYTHON_CC variables, then configure
does
> work, but
> > the rest of the compile fails (because various makefiles are
trying
> to
> > point to the python files but can’t find them).
> >
> > From a quick look in the MET email list archives, it appears
I’m not
> the
> > first to have a similar problem, but I can’t identify what the
actual
> > solution is. I’ve tried with both gnu and pgi compilers and
get the
> same
> > issue.
> >
> > Any help would be welcome. Thanks much!
> >
> > Russ
> >
> >
> >
> >
> >
> > —
> > Russ S. Schumacher
> > Director, Colorado Climate Center
> > Colorado State Climatologist
> > Associate Professor, Department of Atmospheric Science
> > Colorado State University
> > e-mail: russ.schumacher at colostate.edu<mailto:
> russ.schumacher at colostate.edu
> > >
> > phone: 970.491.8084
> > web:
https://www.atmos.colostate.edu/people/faculty/schumacher/
> >
> >
> >
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research
> Research Applications Laboratory
> 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.
>
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
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: [rt.rap.ucar.edu #96902] errors in compiling met9.1
From: Russ Schumacher
Time: Wed Sep 30 19:51:55 2020
Thanks, Julie.
I found that the 'system' install of python didn't even have the
python-config command installed. But I activated miniconda and used
that version to follow these steps. I used these values:
export MET_PYTHON=/home/rschumac/miniconda3/bin/python
export MET_PYTHON_LD="-
L/home/rschumac/miniconda3/lib/python3.8/config-3.8-x86_64-linux-gnu
-L/home/rschumac/miniconda3/lib -lpython3.8 -lcrypt -lpthread -ldl
-lutil -lrt -lm -lm"
export MET_PYTHON_CC="-I/home/rschumac/miniconda3/include/python3.8"
And that succeeded in getting past the configure stage!
During the MET compile though, another error arose while compiling
ensemble-stat:
lto1: fatal error: bytecode stream in file
‘/home/rschumac/miniconda3/lib/python3.8/config-3.8-x86_64-linux-
gnu/libpython3.8.a’ generated with LTO version 6.0 instead of the
expected 7.1
compilation terminated.
lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
>From google searching, it seems that this has to do with linking
against code that was compiled with an older version of the compiler.
So I'm not sure if there's an easy solution to that, but I'm
interested if you have any ideas.
Thanks for the help!
Russ
On 9/30/20, 5:59 PM, "Julie Prestopnik via RT" <met_help at ucar.edu>
wrote:
Hi Russ.
Thanks so much for sending the files. They are very useful.
Did you happen to run the command "python3-config --ldflags" to
get the
value for MET_PYTHON_LD? If not, please run that command and let
me know
what it returns. If so, it is unfortunate, because it is not
telling us
the location of the Python library file, which we need for MET.
Since the
include file is in "/usr/include/python3.7m", I can look at a
similar
structure on one of our machines and see the library file here:
> find /usr/lib/python3.5 -name "*libpython*"
>
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5.so
>
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m.so
>
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m.a
>
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m-
pic.a
>
So, perhaps your library file is in a similar directory, in which
case you
would try setting MET_PYTHON_LD in the following way:
export MET_PYTHON_LD=-L/usr/lib/python3.7/config-3.7m-x86_64-
linux-gnu\
> -lpython3.7\ -lcrypt\ -lpthread\ -ldl\ -lutil\ -lm\ -Xlinker\
> -export-dynamic
>
Please note the addition of the "-L" followed by the path and also
the
removal of the quotation marks around the value.
Give that a shot and let us know how it goes. If it still does
not
compile, please send your new config.log file. Thanks!
Julie
------------------------------------------------
Subject: errors in compiling met9.1
From: Julie Prestopnik
Time: Wed Sep 30 20:36:29 2020
Hi Russ.
This is interesting and something I have not encountered previously.
You could go back to using Python in the /usr area, manually finding
the
Python library file and modifying MET_PYTHON_LD as described in the
last
email and see if that works.
Likely all of the external libraries you used previously were compiled
with
"gcc version 8.3.0 (Debian 8.3.0-6)" as indicated in the config.log
file
you sent.
When I'm one of our Linux machines and I run:
> jpresto:~> which gcc
>
> /usr/bin/gcc
>
> jpresto:~> gcc --version
>
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
You can see I get gcc version 6.3.0.
When I load my anaconda environment and I run:
> (metplus_env) jpresto at kiowa:~$ python
> Python 3.6.3 |Anaconda, Inc.| (default, Nov 20 2017, 20:41:42)
> [GCC 7.2.0] on linux
You can see I get gcc version 7.2.0.
What version of gcc do you see if you run "python" in your conda
environment?
Julie
On Wed, Sep 30, 2020 at 7:52 PM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96902 >
>
> Thanks, Julie.
>
> I found that the 'system' install of python didn't even have the
> python-config command installed. But I activated miniconda and used
that
> version to follow these steps. I used these values:
>
> export MET_PYTHON=/home/rschumac/miniconda3/bin/python
> export
> MET_PYTHON_LD="-L/home/rschumac/miniconda3/lib/python3.8/config-3.8-
x86_64-linux-gnu
> -L/home/rschumac/miniconda3/lib -lpython3.8 -lcrypt -lpthread -ldl
-lutil
> -lrt -lm -lm"
> export MET_PYTHON_CC="-I/home/rschumac/miniconda3/include/python3.8"
>
> And that succeeded in getting past the configure stage!
>
> During the MET compile though, another error arose while compiling
> ensemble-stat:
>
> lto1: fatal error: bytecode stream in file
> ‘/home/rschumac/miniconda3/lib/python3.8/config-3.8-x86_64-linux-
gnu/libpython3.8.a’
> generated with LTO version 6.0 instead of the expected 7.1
> compilation terminated.
> lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
>
> From google searching, it seems that this has to do with linking
against
> code that was compiled with an older version of the compiler. So I'm
not
> sure if there's an easy solution to that, but I'm interested if you
have
> any ideas.
>
> Thanks for the help!
> Russ
>
>
>
>
>
> On 9/30/20, 5:59 PM, "Julie Prestopnik via RT" <met_help at ucar.edu>
wrote:
>
> Hi Russ.
>
> Thanks so much for sending the files. They are very useful.
>
> Did you happen to run the command "python3-config --ldflags" to
get the
> value for MET_PYTHON_LD? If not, please run that command and
let me
> know
> what it returns. If so, it is unfortunate, because it is not
telling
> us
> the location of the Python library file, which we need for MET.
Since
> the
> include file is in "/usr/include/python3.7m", I can look at a
similar
> structure on one of our machines and see the library file here:
>
> > find /usr/lib/python3.5 -name "*libpython*"
> >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5.so
> >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5m.so
> >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5m.a
> >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m-
pic.a
> >
>
> So, perhaps your library file is in a similar directory, in
which case
> you
> would try setting MET_PYTHON_LD in the following way:
>
> export MET_PYTHON_LD=-L/usr/lib/python3.7/config-3.7m-x86_64-
linux-gnu\
> > -lpython3.7\ -lcrypt\ -lpthread\ -ldl\ -lutil\ -lm\ -Xlinker\
> > -export-dynamic
> >
>
>
> Please note the addition of the "-L" followed by the path and
also the
> removal of the quotation marks around the value.
>
> Give that a shot and let us know how it goes. If it still does
not
> compile, please send your new config.log file. Thanks!
>
> Julie
>
>
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
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: [rt.rap.ucar.edu #96902] errors in compiling met9.1
From: Russ Schumacher
Time: Wed Sep 30 21:32:36 2020
Hi Julie,
Yes - the anaconda python gcc was a different version, 7.3.0 in my
case (compared to 8.3.0 that I was using to compile).
So as you suggested I went back to the system install of python and
got it working. The lines in the input file that ended up working
were:
export MET_PYTHON=/usr/bin/python3.7m
export MET_PYTHON_LD="-L/usr/lib/python3.7/config-3.7m-x86_64-linux-
gnu -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm -Xlinker -export-
dynamic"
export MET_PYTHON_CC="-I/usr/include/python3.7m"
(It also turned out that libpython3.7-dev was not installed on this
new machine, so I needed to install that to get the Python.h file, but
once I did that then the compile finished and all looks well.)
Thanks for all of your help!
Russ
On 9/30/20, 8:36 PM, "Julie Prestopnik via RT" <met_help at ucar.edu>
wrote:
Hi Russ.
This is interesting and something I have not encountered
previously.
You could go back to using Python in the /usr area, manually
finding the
Python library file and modifying MET_PYTHON_LD as described in
the last
email and see if that works.
Likely all of the external libraries you used previously were
compiled with
"gcc version 8.3.0 (Debian 8.3.0-6)" as indicated in the
config.log file
you sent.
When I'm one of our Linux machines and I run:
> jpresto:~> which gcc
>
> /usr/bin/gcc
>
> jpresto:~> gcc --version
>
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
You can see I get gcc version 6.3.0.
When I load my anaconda environment and I run:
> (metplus_env) jpresto at kiowa:~$ python
> Python 3.6.3 |Anaconda, Inc.| (default, Nov 20 2017, 20:41:42)
> [GCC 7.2.0] on linux
You can see I get gcc version 7.2.0.
What version of gcc do you see if you run "python" in your conda
environment?
Julie
On Wed, Sep 30, 2020 at 7:52 PM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> <URL:
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D96902&data=02%7C01%7Cruss.schumacher%40colostate.edu%7Cd5a3b781d6814749dc9208d865b2ce95%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637371165943524983&sdata=WcEK9ewO9t6PO%2BneQ6G3D6%2Bf%2FKG5vlgJMcqj59U%2FSPM%3D&reserved=0
>
>
> Thanks, Julie.
>
> I found that the 'system' install of python didn't even have the
> python-config command installed. But I activated miniconda and
used that
> version to follow these steps. I used these values:
>
> export MET_PYTHON=/home/rschumac/miniconda3/bin/python
> export
> MET_PYTHON_LD="-L/home/rschumac/miniconda3/lib/python3.8/config-
3.8-x86_64-linux-gnu
> -L/home/rschumac/miniconda3/lib -lpython3.8 -lcrypt -lpthread
-ldl -lutil
> -lrt -lm -lm"
> export MET_PYTHON_CC="-
I/home/rschumac/miniconda3/include/python3.8"
>
> And that succeeded in getting past the configure stage!
>
> During the MET compile though, another error arose while
compiling
> ensemble-stat:
>
> lto1: fatal error: bytecode stream in file
> ‘/home/rschumac/miniconda3/lib/python3.8/config-3.8-x86_64-
linux-gnu/libpython3.8.a’
> generated with LTO version 6.0 instead of the expected 7.1
> compilation terminated.
> lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
>
> From google searching, it seems that this has to do with linking
against
> code that was compiled with an older version of the compiler. So
I'm not
> sure if there's an easy solution to that, but I'm interested if
you have
> any ideas.
>
> Thanks for the help!
> Russ
>
>
>
>
>
> On 9/30/20, 5:59 PM, "Julie Prestopnik via RT"
<met_help at ucar.edu> wrote:
>
> Hi Russ.
>
> Thanks so much for sending the files. They are very useful.
>
> Did you happen to run the command "python3-config --ldflags"
to get the
> value for MET_PYTHON_LD? If not, please run that command
and let me
> know
> what it returns. If so, it is unfortunate, because it is
not telling
> us
> the location of the Python library file, which we need for
MET. Since
> the
> include file is in "/usr/include/python3.7m", I can look at
a similar
> structure on one of our machines and see the library file
here:
>
> > find /usr/lib/python3.5 -name "*libpython*"
> >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5.so
> >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5m.so
> >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5m.a
> >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5m-pic.a
> >
>
> So, perhaps your library file is in a similar directory, in
which case
> you
> would try setting MET_PYTHON_LD in the following way:
>
> export MET_PYTHON_LD=-L/usr/lib/python3.7/config-3.7m-
x86_64-linux-gnu\
> > -lpython3.7\ -lcrypt\ -lpthread\ -ldl\ -lutil\ -lm\
-Xlinker\
> > -export-dynamic
> >
>
>
> Please note the addition of the "-L" followed by the path
and also the
> removal of the quotation marks around the value.
>
> Give that a shot and let us know how it goes. If it still
does not
> compile, please send your new config.log file. Thanks!
>
> Julie
>
>
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
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: errors in compiling met9.1
From: Julie Prestopnik
Time: Thu Oct 01 07:36:47 2020
I'm so glad you were able to get it working! Thanks for the update
and for
sending me what worked and for figuring out you needed to
libpython3.7-dev.
If you'd prefer to get it working with anaconda, we can probably do
that
too. I'm not very familiar with anaconda, but I hope there would be a
way
to get the 8.3.0 compiler, and theoretically that should work as well.
Julie
On Wed, Sep 30, 2020 at 9:32 PM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96902 >
>
> Hi Julie,
>
> Yes - the anaconda python gcc was a different version, 7.3.0 in my
case
> (compared to 8.3.0 that I was using to compile).
>
> So as you suggested I went back to the system install of python and
got it
> working. The lines in the input file that ended up working were:
>
> export MET_PYTHON=/usr/bin/python3.7m
> export MET_PYTHON_LD="-L/usr/lib/python3.7/config-3.7m-x86_64-linux-
gnu
> -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm -Xlinker -export-
dynamic"
> export MET_PYTHON_CC="-I/usr/include/python3.7m"
>
> (It also turned out that libpython3.7-dev was not installed on this
new
> machine, so I needed to install that to get the Python.h file, but
once I
> did that then the compile finished and all looks well.)
>
> Thanks for all of your help!
>
> Russ
>
>
>
>
> On 9/30/20, 8:36 PM, "Julie Prestopnik via RT" <met_help at ucar.edu>
wrote:
>
> Hi Russ.
>
> This is interesting and something I have not encountered
previously.
>
> You could go back to using Python in the /usr area, manually
finding
> the
> Python library file and modifying MET_PYTHON_LD as described in
the
> last
> email and see if that works.
>
> Likely all of the external libraries you used previously were
compiled
> with
> "gcc version 8.3.0 (Debian 8.3.0-6)" as indicated in the
config.log
> file
> you sent.
>
> When I'm one of our Linux machines and I run:
>
> > jpresto:~> which gcc
> >
> > /usr/bin/gcc
> >
> > jpresto:~> gcc --version
> >
> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
>
> You can see I get gcc version 6.3.0.
>
> When I load my anaconda environment and I run:
>
> > (metplus_env) jpresto at kiowa:~$ python
> > Python 3.6.3 |Anaconda, Inc.| (default, Nov 20 2017, 20:41:42)
> > [GCC 7.2.0] on linux
>
> You can see I get gcc version 7.2.0.
>
> What version of gcc do you see if you run "python" in your conda
> environment?
>
> Julie
>
> On Wed, Sep 30, 2020 at 7:52 PM Russ Schumacher via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > <URL:
>
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D96902&data=02%7C01%7Cruss.schumacher%40colostate.edu%7Cd5a3b781d6814749dc9208d865b2ce95%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637371165943524983&sdata=WcEK9ewO9t6PO%2BneQ6G3D6%2Bf%2FKG5vlgJMcqj59U%2FSPM%3D&reserved=0
> >
> >
> > Thanks, Julie.
> >
> > I found that the 'system' install of python didn't even have
the
> > python-config command installed. But I activated miniconda
and used
> that
> > version to follow these steps. I used these values:
> >
> > export MET_PYTHON=/home/rschumac/miniconda3/bin/python
> > export
> >
> MET_PYTHON_LD="-L/home/rschumac/miniconda3/lib/python3.8/config-3.8-
x86_64-linux-gnu
> > -L/home/rschumac/miniconda3/lib -lpython3.8 -lcrypt -lpthread
-ldl
> -lutil
> > -lrt -lm -lm"
> > export MET_PYTHON_CC="-
I/home/rschumac/miniconda3/include/python3.8"
> >
> > And that succeeded in getting past the configure stage!
> >
> > During the MET compile though, another error arose while
compiling
> > ensemble-stat:
> >
> > lto1: fatal error: bytecode stream in file
> >
> ‘/home/rschumac/miniconda3/lib/python3.8/config-3.8-x86_64-linux-
gnu/libpython3.8.a’
> > generated with LTO version 6.0 instead of the expected 7.1
> > compilation terminated.
> > lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
> > compilation terminated.
> > /usr/bin/ld: error: lto-wrapper failed
> >
> > From google searching, it seems that this has to do with
linking
> against
> > code that was compiled with an older version of the compiler.
So I'm
> not
> > sure if there's an easy solution to that, but I'm interested
if you
> have
> > any ideas.
> >
> > Thanks for the help!
> > Russ
> >
> >
> >
> >
> >
> > On 9/30/20, 5:59 PM, "Julie Prestopnik via RT"
<met_help at ucar.edu>
> wrote:
> >
> > Hi Russ.
> >
> > Thanks so much for sending the files. They are very
useful.
> >
> > Did you happen to run the command "python3-config
--ldflags" to
> get the
> > value for MET_PYTHON_LD? If not, please run that command
and
> let me
> > know
> > what it returns. If so, it is unfortunate, because it is
not
> telling
> > us
> > the location of the Python library file, which we need for
MET.
> Since
> > the
> > include file is in "/usr/include/python3.7m", I can look
at a
> similar
> > structure on one of our machines and see the library file
here:
> >
> > > find /usr/lib/python3.5 -name "*libpython*"
> > >
> > > /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/
> libpython3.5.so
> > >
> > > /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/
> libpython3.5m.so
> > >
> > > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5m.a
> > >
> > >
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m-pic.a
> > >
> >
> > So, perhaps your library file is in a similar directory,
in
> which case
> > you
> > would try setting MET_PYTHON_LD in the following way:
> >
> > export
> MET_PYTHON_LD=-L/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu\
> > > -lpython3.7\ -lcrypt\ -lpthread\ -ldl\ -lutil\ -lm\
-Xlinker\
> > > -export-dynamic
> > >
> >
> >
> > Please note the addition of the "-L" followed by the path
and
> also the
> > removal of the quotation marks around the value.
> >
> > Give that a shot and let us know how it goes. If it still
does
> not
> > compile, please send your new config.log file. Thanks!
> >
> > Julie
> >
> >
> >
> >
> >
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research
> Research Applications Laboratory
> 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.
>
>
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
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: [rt.rap.ucar.edu #96902] errors in compiling met9.1
From: Russ Schumacher
Time: Thu Oct 01 08:58:19 2020
Thanks, Julie. What I have will work great. I see that anaconda
apparently has their own set of compilers now so I suppose that could
be the solution, but I'm not going to invest time into figuring that
out right now. Thanks for all of your help!
Russ
On 10/1/20, 7:36 AM, "Julie Prestopnik via RT" <met_help at ucar.edu>
wrote:
I'm so glad you were able to get it working! Thanks for the
update and for
sending me what worked and for figuring out you needed to
libpython3.7-dev.
If you'd prefer to get it working with anaconda, we can probably
do that
too. I'm not very familiar with anaconda, but I hope there would
be a way
to get the 8.3.0 compiler, and theoretically that should work as
well.
Julie
On Wed, Sep 30, 2020 at 9:32 PM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> <URL:
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D96902&data=02%7C01%7Cruss.schumacher%40colostate.edu%7Cd749667c0aa64cbf0c1808d8660f0c81%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637371562114321644&sdata=SmwrN91Z5aWMSAYJG%2FcRlgl8%2B5rfmVgcaXbSfwJZuwY%3D&reserved=0
>
>
> Hi Julie,
>
> Yes - the anaconda python gcc was a different version, 7.3.0 in
my case
> (compared to 8.3.0 that I was using to compile).
>
> So as you suggested I went back to the system install of python
and got it
> working. The lines in the input file that ended up working
were:
>
> export MET_PYTHON=/usr/bin/python3.7m
> export MET_PYTHON_LD="-L/usr/lib/python3.7/config-3.7m-x86_64-
linux-gnu
> -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm -Xlinker -export-
dynamic"
> export MET_PYTHON_CC="-I/usr/include/python3.7m"
>
> (It also turned out that libpython3.7-dev was not installed on
this new
> machine, so I needed to install that to get the Python.h file,
but once I
> did that then the compile finished and all looks well.)
>
> Thanks for all of your help!
>
> Russ
>
>
>
>
> On 9/30/20, 8:36 PM, "Julie Prestopnik via RT"
<met_help at ucar.edu> wrote:
>
> Hi Russ.
>
> This is interesting and something I have not encountered
previously.
>
> You could go back to using Python in the /usr area, manually
finding
> the
> Python library file and modifying MET_PYTHON_LD as described
in the
> last
> email and see if that works.
>
> Likely all of the external libraries you used previously
were compiled
> with
> "gcc version 8.3.0 (Debian 8.3.0-6)" as indicated in the
config.log
> file
> you sent.
>
> When I'm one of our Linux machines and I run:
>
> > jpresto:~> which gcc
> >
> > /usr/bin/gcc
> >
> > jpresto:~> gcc --version
> >
> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
>
> You can see I get gcc version 6.3.0.
>
> When I load my anaconda environment and I run:
>
> > (metplus_env) jpresto at kiowa:~$ python
> > Python 3.6.3 |Anaconda, Inc.| (default, Nov 20 2017,
20:41:42)
> > [GCC 7.2.0] on linux
>
> You can see I get gcc version 7.2.0.
>
> What version of gcc do you see if you run "python" in your
conda
> environment?
>
> Julie
>
> On Wed, Sep 30, 2020 at 7:52 PM Russ Schumacher via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > <URL:
>
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D96902&data=02%7C01%7Cruss.schumacher%40colostate.edu%7Cd749667c0aa64cbf0c1808d8660f0c81%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637371562114321644&sdata=SmwrN91Z5aWMSAYJG%2FcRlgl8%2B5rfmVgcaXbSfwJZuwY%3D&reserved=0
> >
> >
> > Thanks, Julie.
> >
> > I found that the 'system' install of python didn't even
have the
> > python-config command installed. But I activated
miniconda and used
> that
> > version to follow these steps. I used these values:
> >
> > export MET_PYTHON=/home/rschumac/miniconda3/bin/python
> > export
> >
> MET_PYTHON_LD="-L/home/rschumac/miniconda3/lib/python3.8/config-
3.8-x86_64-linux-gnu
> > -L/home/rschumac/miniconda3/lib -lpython3.8 -lcrypt
-lpthread -ldl
> -lutil
> > -lrt -lm -lm"
> > export MET_PYTHON_CC="-
I/home/rschumac/miniconda3/include/python3.8"
> >
> > And that succeeded in getting past the configure stage!
> >
> > During the MET compile though, another error arose while
compiling
> > ensemble-stat:
> >
> > lto1: fatal error: bytecode stream in file
> >
> ‘/home/rschumac/miniconda3/lib/python3.8/config-3.8-x86_64-
linux-gnu/libpython3.8.a’
> > generated with LTO version 6.0 instead of the expected 7.1
> > compilation terminated.
> > lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit
status
> > compilation terminated.
> > /usr/bin/ld: error: lto-wrapper failed
> >
> > From google searching, it seems that this has to do with
linking
> against
> > code that was compiled with an older version of the
compiler. So I'm
> not
> > sure if there's an easy solution to that, but I'm
interested if you
> have
> > any ideas.
> >
> > Thanks for the help!
> > Russ
> >
> >
> >
> >
> >
> > On 9/30/20, 5:59 PM, "Julie Prestopnik via RT"
<met_help at ucar.edu>
> wrote:
> >
> > Hi Russ.
> >
> > Thanks so much for sending the files. They are very
useful.
> >
> > Did you happen to run the command "python3-config
--ldflags" to
> get the
> > value for MET_PYTHON_LD? If not, please run that
command and
> let me
> > know
> > what it returns. If so, it is unfortunate, because it
is not
> telling
> > us
> > the location of the Python library file, which we need
for MET.
> Since
> > the
> > include file is in "/usr/include/python3.7m", I can
look at a
> similar
> > structure on one of our machines and see the library
file here:
> >
> > > find /usr/lib/python3.5 -name "*libpython*"
> > >
> > > /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/
> libpython3.5.so
> > >
> > > /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/
> libpython3.5m.so
> > >
> > > /usr/lib/python3.5/config-3.5m-x86_64-linux-
gnu/libpython3.5m.a
> > >
> > >
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m-
pic.a
> > >
> >
> > So, perhaps your library file is in a similar
directory, in
> which case
> > you
> > would try setting MET_PYTHON_LD in the following way:
> >
> > export
> MET_PYTHON_LD=-L/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu\
> > > -lpython3.7\ -lcrypt\ -lpthread\ -ldl\ -lutil\ -lm\
-Xlinker\
> > > -export-dynamic
> > >
> >
> >
> > Please note the addition of the "-L" followed by the
path and
> also the
> > removal of the quotation marks around the value.
> >
> > Give that a shot and let us know how it goes. If it
still does
> not
> > compile, please send your new config.log file.
Thanks!
> >
> > Julie
> >
> >
> >
> >
> >
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research
> Research Applications Laboratory
> 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.
>
>
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
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: errors in compiling met9.1
From: Julie Prestopnik
Time: Thu Oct 01 09:01:24 2020
Ok, great! Thanks for letting me know. I'll go ahead and close this
ticket, but please let us know if you have any other questions or
issues.
Julie
On Thu, Oct 1, 2020 at 8:58 AM Russ Schumacher via RT
<met_help at ucar.edu>
wrote:
>
> <URL: https://rt.rap.ucar.edu/rt/Ticket/Display.html?id=96902 >
>
> Thanks, Julie. What I have will work great. I see that anaconda
apparently
> has their own set of compilers now so I suppose that could be the
solution,
> but I'm not going to invest time into figuring that out right now.
Thanks
> for all of your help!
>
> Russ
>
>
> On 10/1/20, 7:36 AM, "Julie Prestopnik via RT" <met_help at ucar.edu>
wrote:
>
> I'm so glad you were able to get it working! Thanks for the
update
> and for
> sending me what worked and for figuring out you needed to
> libpython3.7-dev.
>
> If you'd prefer to get it working with anaconda, we can probably
do
> that
> too. I'm not very familiar with anaconda, but I hope there
would be a
> way
> to get the 8.3.0 compiler, and theoretically that should work as
well.
>
> Julie
>
> On Wed, Sep 30, 2020 at 9:32 PM Russ Schumacher via RT <
> met_help at ucar.edu>
> wrote:
>
> >
> > <URL:
>
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D96902&data=02%7C01%7Cruss.schumacher%40colostate.edu%7Cd749667c0aa64cbf0c1808d8660f0c81%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637371562114321644&sdata=SmwrN91Z5aWMSAYJG%2FcRlgl8%2B5rfmVgcaXbSfwJZuwY%3D&reserved=0
> >
> >
> > Hi Julie,
> >
> > Yes - the anaconda python gcc was a different version, 7.3.0
in my
> case
> > (compared to 8.3.0 that I was using to compile).
> >
> > So as you suggested I went back to the system install of
python and
> got it
> > working. The lines in the input file that ended up working
were:
> >
> > export MET_PYTHON=/usr/bin/python3.7m
> > export
> MET_PYTHON_LD="-L/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu
> > -lpython3.7m -lcrypt -lpthread -ldl -lutil -lm -Xlinker
> -export-dynamic"
> > export MET_PYTHON_CC="-I/usr/include/python3.7m"
> >
> > (It also turned out that libpython3.7-dev was not installed on
this
> new
> > machine, so I needed to install that to get the Python.h file,
but
> once I
> > did that then the compile finished and all looks well.)
> >
> > Thanks for all of your help!
> >
> > Russ
> >
> >
> >
> >
> > On 9/30/20, 8:36 PM, "Julie Prestopnik via RT"
<met_help at ucar.edu>
> wrote:
> >
> > Hi Russ.
> >
> > This is interesting and something I have not encountered
> previously.
> >
> > You could go back to using Python in the /usr area,
manually
> finding
> > the
> > Python library file and modifying MET_PYTHON_LD as
described in
> the
> > last
> > email and see if that works.
> >
> > Likely all of the external libraries you used previously
were
> compiled
> > with
> > "gcc version 8.3.0 (Debian 8.3.0-6)" as indicated in the
> config.log
> > file
> > you sent.
> >
> > When I'm one of our Linux machines and I run:
> >
> > > jpresto:~> which gcc
> > >
> > > /usr/bin/gcc
> > >
> > > jpresto:~> gcc --version
> > >
> > gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> >
> > You can see I get gcc version 6.3.0.
> >
> > When I load my anaconda environment and I run:
> >
> > > (metplus_env) jpresto at kiowa:~$ python
> > > Python 3.6.3 |Anaconda, Inc.| (default, Nov 20 2017,
20:41:42)
> > > [GCC 7.2.0] on linux
> >
> > You can see I get gcc version 7.2.0.
> >
> > What version of gcc do you see if you run "python" in your
conda
> > environment?
> >
> > Julie
> >
> > On Wed, Sep 30, 2020 at 7:52 PM Russ Schumacher via RT <
> > met_help at ucar.edu>
> > wrote:
> >
> > >
> > > <URL:
> >
>
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frt.rap.ucar.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D96902&data=02%7C01%7Cruss.schumacher%40colostate.edu%7Cd749667c0aa64cbf0c1808d8660f0c81%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637371562114321644&sdata=SmwrN91Z5aWMSAYJG%2FcRlgl8%2B5rfmVgcaXbSfwJZuwY%3D&reserved=0
> > >
> > >
> > > Thanks, Julie.
> > >
> > > I found that the 'system' install of python didn't even
have
> the
> > > python-config command installed. But I activated
miniconda
> and used
> > that
> > > version to follow these steps. I used these values:
> > >
> > > export MET_PYTHON=/home/rschumac/miniconda3/bin/python
> > > export
> > >
> >
> MET_PYTHON_LD="-L/home/rschumac/miniconda3/lib/python3.8/config-3.8-
x86_64-linux-gnu
> > > -L/home/rschumac/miniconda3/lib -lpython3.8 -lcrypt
-lpthread
> -ldl
> > -lutil
> > > -lrt -lm -lm"
> > > export
> MET_PYTHON_CC="-I/home/rschumac/miniconda3/include/python3.8"
> > >
> > > And that succeeded in getting past the configure stage!
> > >
> > > During the MET compile though, another error arose while
> compiling
> > > ensemble-stat:
> > >
> > > lto1: fatal error: bytecode stream in file
> > >
> >
> ‘/home/rschumac/miniconda3/lib/python3.8/config-3.8-x86_64-linux-
gnu/libpython3.8.a’
> > > generated with LTO version 6.0 instead of the expected
7.1
> > > compilation terminated.
> > > lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit
status
> > > compilation terminated.
> > > /usr/bin/ld: error: lto-wrapper failed
> > >
> > > From google searching, it seems that this has to do with
> linking
> > against
> > > code that was compiled with an older version of the
compiler.
> So I'm
> > not
> > > sure if there's an easy solution to that, but I'm
interested
> if you
> > have
> > > any ideas.
> > >
> > > Thanks for the help!
> > > Russ
> > >
> > >
> > >
> > >
> > >
> > > On 9/30/20, 5:59 PM, "Julie Prestopnik via RT" <
> met_help at ucar.edu>
> > wrote:
> > >
> > > Hi Russ.
> > >
> > > Thanks so much for sending the files. They are very
> useful.
> > >
> > > Did you happen to run the command "python3-config
> --ldflags" to
> > get the
> > > value for MET_PYTHON_LD? If not, please run that
command
> and
> > let me
> > > know
> > > what it returns. If so, it is unfortunate, because
it is
> not
> > telling
> > > us
> > > the location of the Python library file, which we
need for
> MET.
> > Since
> > > the
> > > include file is in "/usr/include/python3.7m", I can
look
> at a
> > similar
> > > structure on one of our machines and see the library
file
> here:
> > >
> > > > find /usr/lib/python3.5 -name "*libpython*"
> > > >
> > > > /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/
> > libpython3.5.so
> > > >
> > > > /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/
> > libpython3.5m.so
> > > >
> > > >
> /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m.a
> > > >
> > > >
> > /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/libpython3.5m-
pic.a
> > > >
> > >
> > > So, perhaps your library file is in a similar
directory, in
> > which case
> > > you
> > > would try setting MET_PYTHON_LD in the following
way:
> > >
> > > export
> > MET_PYTHON_LD=-L/usr/lib/python3.7/config-3.7m-x86_64-linux-
gnu\
> > > > -lpython3.7\ -lcrypt\ -lpthread\ -ldl\ -lutil\
-lm\
> -Xlinker\
> > > > -export-dynamic
> > > >
> > >
> > >
> > > Please note the addition of the "-L" followed by the
path
> and
> > also the
> > > removal of the quotation marks around the value.
> > >
> > > Give that a shot and let us know how it goes. If it
still
> does
> > not
> > > compile, please send your new config.log file.
Thanks!
> > >
> > > Julie
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Julie Prestopnik (she/her/hers)
> > Software Engineer
> > National Center for Atmospheric Research
> > Research Applications Laboratory
> > 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.
> >
> >
> >
> >
> >
>
> --
> Julie Prestopnik (she/her/hers)
> Software Engineer
> National Center for Atmospheric Research
> Research Applications Laboratory
> 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.
>
>
>
>
>
--
Julie Prestopnik (she/her/hers)
Software Engineer
National Center for Atmospheric Research
Research Applications Laboratory
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