pip compilation issues #131
Comments
|
It's a mess, I know--believe me. Thank you for trying to document this. Some things that come to mind here:
|
|
What if you insert this line: above this one? (and insert a |
|
I still get the same errors (no new ones). Compilations fails with
PYCVODES_USE_LAPACK='0' or unset and compiles with it set to '1'.
…On Sat, Oct 31, 2020 at 6:09 AM Bjorn ***@***.***> wrote:
What if you insert this line:
#ifndef _SUNDIALS_LAPACK_H
above this one?
https://github.com/bjodah/anyode/blob/ce9db8c91adf036657219a3cdf3c251483a3f0f7/include/anyode/anyode_blas_lapack.hpp#L2
(and insert a #endif after the relevant extern declarations?)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#131 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQCHS332HKUD5FPHY5UNS3SNPV7FANCNFSM4TEID3FQ>
.
--
Jeremy A. Gray
|
|
sorry, I don't quite follow, did you export environment variables on the command line prior to installing?, i.e.: regarding requirements.txt, I think it's deprecated since 5 years or so? setuptools & requires arguments are preferred I believe? (way back, I used to maintain a requirements.txt in the repository even...) |
|
I added the #ifndef/#endif, then cleared the environment so that
`PYCVODES_NO_LAPACK`
was unset so that it would build as normal with `python setup.py build` in
the pycvodes top directory, and I got the same multiple definition errors.
Then, I exported and ran `export PYCVODES_NO_LAPACK='1' && python setup.py
build` in the pycvodes top directory and successfully compiled. I do the
same test with chempy (with and without `PYCVODES_NO_LAPACK` in the
environment), and install always fails on pycvodes if `PYCVODES_NO_LAPACK='1'`
is not set in the environment. I have not changed `PYCVODES_NO_KLU`.
I'm using `requirements.txt` (in chempy) right now as a list to get a
virtualenv set up for testing and development (deployment only, not
packaging and installing chempy).
…On Sat, Oct 31, 2020 at 10:50 AM Bjorn ***@***.***> wrote:
sorry, I don't quite follow, did you export environment variables on the
command line prior to installing?, i.e.:
export PYCVODES_NO_LAPACK=1 PYCVODES_NO_KLU=1
python3 -m pip install .
regarding requirements.txt, I think it's deprecated since 5 years or so?
setuptools & requires arguments are preferred I believe? (way back, I used
to maintain a requirements.txt in the repository even...)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#131 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQCHS53WZ6TW4AXYMR4AJTSNQW6BANCNFSM4TEID3FQ>
.
--
Jeremy A. Gray
|
|
Alright, hard to say exactly why it is failing. Support for both with & without lapack was added to allow compilation of sundials with When one has multiple versions of sundials on the same machine, I have found that my sanity is best preserved by directly setting CFLAGS & LDFLAGS: |
|
Let me see if I understand everything. I intend to have just one sundials
installation. I have lapack, blas, boost, suitesparse, gsl, and sundials
either in the system include/ld paths or in a searched path, so all of them
can include and link with each other as necessary (and I can adjust
CFLAGS/LDFLAGS if necessary). So if sundials is compiled without klu and
lapack, does pycvodes/anyode include/link with suitesparse and lapack
directly? Is there any functionality lost that might be useful in
pycvodes or chempy?
I think my question and this issue rests on how sundials should be
configured before compilation because `.drone.yml` indicates that sundials
should be compiled without klu and lapack. Or alternatively, if sundials
is compiled with certain features (klu or lapack), should
pycvodes/anyode ignore parts of the sundials interface in deference to the
implementation in pycvodes/anyode?
…On Sat, Oct 31, 2020 at 11:44 AM Bjorn ***@***.***> wrote:
Alright, hard to say exactly why it is failing. Supporting both with &
without lapack done to allow compilation of sundials with long double
(which BLAS/LAPACK does not support). There's been a lot of back and forth
in this area over the years, simply because each new environment has
essentially shown to need its own treatment.
When one has multiple versions of sundials on the same machine, I have
found that my sanity is best preserved by directly setting CFLAGS & LDFLAGS:
export CFLAGS="-isystem /opt/sundials-5.2.0-noklu-nolapack-extended-int64/include -DPYCVODES_NO_KLU=1 -DPYCVODES_NO_LAPACK=1"
export LDFLAGS="-Wl,--disable-new-dtags -Wl,-rpath,/opt/sundials-5.2.0-noklu-nolapack-extended-int64/lib -L/opt/sundials-5.2.0-noklu-nolapack-extended-int64/lib"
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#131 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQCHS24DN6Q43SDJEQVILDSNQ5H5ANCNFSM4TEID3FQ>
.
--
Jeremy A. Gray
|
It should not.
No, after some problem size LAPACK will be faster, but for small problems, I've seen the inverse, i.e. not using LAPACK is significantly faster. pycvodes can exploit matrix sparseness when KLU is available. ChemPy does not use this however. Right now I just upgraded the Debian version to Bullseye in the Dockerfile in ChemPy's repository: All tests pass in that environment (you need docker installed to run that script on your machine in case you want to compare). |
|
I've finally tracked down the source of the issue, but I don't know enough
about C++ to completely understand what is happening. Since we tried an
include guard with `#ifndef _SUNDIALS_LAPACK_H` and it did not work, I
tried some other variations that also failed. After some research, I found
that the include guards work against multiple inclusion but not multiple
definition. Changing all the `extern "C"` in
`anyode/include/anyode/anyode_blas_lapack.h` to just `extern` allowed
pycvodes to build without error (tests ran successfully). I would assume
this has something to do with sundials using `extern "C"` in
`sundials_lapack.h`.
This is on debian bullseye current, with sundials-5.5.0 compiled with
```
cmake -DCMAKE_INSTALL_PREFIX=/home/gray/.local -DLAPACK_ENABLE=ON
-DKLU_ENABLE=ON -DKLU_INCLUDE_DIR=/usr/include/suitesparse
-DKLU_LIBRARY_DIR=/usr/lib/x86_64-linux-gnu .. && make && make install
```
…On Tue, Nov 24, 2020 at 3:05 AM Bjorn ***@***.***> wrote:
So if sundials is compiled without klu and
lapack, does pycvodes/anyode include/link with suitesparse and lapack
directly?
It should not.
Is there any functionality lost that might be useful in
pycvodes or chempy?
No, after some problem size LAPACK will be faster, but for small problems,
I've seen the inverse, i.e. not using LAPACK is *significantly* faster.
pycvodes can exploit matrix sparseness when KLU is available. ChemPy does
not use this however.
Right now I just upgraded the Debian version to Bullseye in the Dockerfile
in ChemPy's repository:
bjodah/chempy#186 <bjodah/chempy#186>
All tests pass in that environment (you need docker installed to run that
script on your machine in case you want to compare).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#131 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQCHS3KYTYIO75JSVTIERLSRNZMVANCNFSM4TEID3FQ>
.
--
Jeremy A. Gray
|
|
Oh, that's a tricky one. |
I keep having a multiple definition error of several functions when using sundials with lapack and pycvodes trying to use headers in anyode. I created a branch to illustrate how I finally got it to compile and install (no errors/warnings) by passing in the appropriate enviroment variable (
PYCVODES_USE_LAPACK='1'), but I wonder if there is a problem elsewhere with one of the libraries or something else. I didn't dive deeply enough into the source to see if this turned off all lapack use, but the tests in pycvodes/tests passed. I was intending to work on or at least document pip installation of chempy and got hung on pycvodes.Hopefully all the relevant setup details are below; errors follow.
versions (current debian/bullseye):
requirements.txt:
Build Errors:
python setup.py bdist_wheelThe text was updated successfully, but these errors were encountered: