Conversation
eb51c12 to
8114ca8
Compare
adamjstewart
left a comment
There was a problem hiding this comment.
I like this fix a lot more than mine. Don't think it will work for external Python but at least Spack Python will work.
There was a problem hiding this comment.
I don't want to block this if it solves things, but skimming through the linked issues, we don't understand the underlying issue and don't have a good way to reproduce? Do we know for a fact we're hitting an existing & reported bug in Python's build system?
What about external Python?
In the case of Opensuse the issue here is that the autoconf installed by Opensuse defaults to install libs in lib64, is there a way to conflict with external package. In this manner we can use the spack autoconf.
The configure script is already generated in the release tarball, so that's unrelated. But I guess somewhere there's a discrepancy in install layout, we just don't know where and what the trigger is (given container images don't have the problem). Maybe the cause is some environment variable we should unset during the build of python? Did you try with env -i PATH=... spack install python-venv?
|
I have not yet found the exact reason how opensuse imposes the /lib64 for dependent libraries in this generated configure script in spack, I have one hypothesis: The configure scripts uses an aclocal m4 files that where generated during the spack autoconf installation which sets it to lib64. In any case while my first approach was to force libdir in the autoconf package (which did work as well), I was afraid that this will be a much more involved change and possibly introducing many more errors. For that reason, I decided to just fix the libdir in the Python package. |
|
@adamjstewart there are several failures at the CI, are they expected? |
|
Yeah, you get used to that. @spackbot run pipeline |
|
I've started that pipeline for you! |
|
@haampie I wonder if you could review this, Thanks! |
|
I'm not a big fan of PRs that treat a symptom of some unknown cause. It leads to adding code that nobody dares to touch in the future. We also don't know if this breaks Python on other distros. I'll spin up an openSUSE vm then and see.
the configure script is part of the tarball, it's the same for everybody. |
|
I cannot reproduce on an openSUSE 15.4 vm, so I wouldn't merge this. Please try what I suggested, clear env variables before spack install: |
|
@haampie this error occurs when you try to install a package that depends on python, lets se |
It appears that the spack autotools class reads the system aclocal.m4 if it exists, it also reads the system pkg-config libdir location if it exists. Install system autoconf and pkg-config in your OpenSUSE vm, no need to have them as external pkgs, also use Opensuse 15.6 since 15.4 is already outdated. |
No luck |
It doesn't?
Doesn't influence it. |
|
My guess is it's a global This is from the I bet you do have a variable |
|
I'm inclined to close this and instead address the underlying issue #48679, which is bigger than python as I expected. Feel free to reopen if you feel like this one-off patch should be merged regardless, but I would prefer a general fix. |
|
Good call @haampie your changes fixed this issue thanks! |
Install python-venv in opensuse leads to this error:
The reason of this is that some of Python libraries are installed in
python.prefix.liband others inpython.prefix.lib64. The reason of this is that OpenSUSE and Fedora (AFAIK) expect arch dependent libs to be installed inlib64, for this reason it setup tools such asautoconfto default arch dependent libraries tolib64.The workaround here is to force all Python libraries to be at
libwhich is where Python packages expect them.After applying this change the build runs without any issue
Closes #37171
Closes #39551