Skip to content

Fix opensuse python build#48575

Closed
vicentebolea wants to merge 1 commit intospack:developfrom
vicentebolea:fix-opensuse-python-build
Closed

Fix opensuse python build#48575
vicentebolea wants to merge 1 commit intospack:developfrom
vicentebolea:fix-opensuse-python-build

Conversation

@vicentebolea
Copy link
Copy Markdown
Member

@vicentebolea vicentebolea commented Jan 14, 2025

Install python-venv in opensuse leads to this error:

==> python-venv: Executing phase: 'install'
==> [2025-01-14-22:11:14.544240] '/home/vicente/Projects/spack/spack/opt/spack/linux-opensuse15-skylake/gcc-13.3.0/python-3.13.0-vwfioycy3ssvuwlpd566ntrk4wkupocb/bin/python3' '-m' 'venv' '--without-pip' '/home/vicente/Projects/spack/spack/opt/spack/linux-opensuse15-skylake/gcc-13.3.0/python-venv-1.0-ockax24mkrbksjtbz5f3ty3tzisovdmx'
Could not find platform dependent libraries <exec_prefix>
Traceback (most recent call last):
  File "<frozen runpy>", line 189, in _run_module_as_main
  File "<frozen runpy>", line 148, in _get_module_details
  File "<frozen runpy>", line 112, in _get_module_details
  File "/home/vicente/Projects/spack/spack/opt/spack/linux-opensuse15-skylake/gcc-13.3.0/python-3.13.0-vwfioycy3ssvuwlpd566ntrk4wkupocb/lib/python3.13/venv/__init__.py", line 10, in <module>
    import subprocess
  File "/home/vicente/Projects/spack/spack/opt/spack/linux-opensuse15-skylake/gcc-13.3.0/python-3.13.0-vwfioycy3ssvuwlpd566ntrk4wkupocb/lib/python3.13/subprocess.py", line 106, in <module>
    from _posixsubprocess import fork_exec as _fork_exec
ModuleNotFoundError: No module named '_posixsubprocess'

The reason of this is that some of Python libraries are installed in python.prefix.lib and others in python.prefix.lib64. The reason of this is that OpenSUSE and Fedora (AFAIK) expect arch dependent libs to be installed in lib64, for this reason it setup tools such as autoconf to default arch dependent libraries to lib64.

The workaround here is to force all Python libraries to be at lib which is where Python packages expect them.

After applying this change the build runs without any issue

Closes #37171
Closes #39551

@vicentebolea vicentebolea force-pushed the fix-opensuse-python-build branch from eb51c12 to 8114ca8 Compare January 14, 2025 22:36
@vicentebolea vicentebolea removed the request for review from cyrush January 14, 2025 22:36
@vicentebolea vicentebolea self-assigned this Jan 15, 2025
Copy link
Copy Markdown
Member

@adamjstewart adamjstewart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

@haampie haampie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@vicentebolea
Copy link
Copy Markdown
Member Author

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.

@vicentebolea
Copy link
Copy Markdown
Member Author

@adamjstewart there are several failures at the CI, are they expected?

@adamjstewart
Copy link
Copy Markdown
Member

Yeah, you get used to that.

@spackbot run pipeline

@spackbot-app
Copy link
Copy Markdown

spackbot-app bot commented Jan 17, 2025

I've started that pipeline for you!

@vicentebolea
Copy link
Copy Markdown
Member Author

@haampie I wonder if you could review this, Thanks!

@haampie
Copy link
Copy Markdown
Member

haampie commented Jan 22, 2025

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 scripts uses an aclocal m4 files that where generated during the spack autoconf installation which sets it to lib64.

the configure script is part of the tarball, it's the same for everybody.

@haampie
Copy link
Copy Markdown
Member

haampie commented Jan 22, 2025

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: env -i ... spack install

@vicentebolea
Copy link
Copy Markdown
Member Author

@haampie this error occurs when you try to install a package that depends on python, lets se spack install python-env

@vicentebolea
Copy link
Copy Markdown
Member Author

the configure script is part of the tarball, it's the same for everybody.

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.

@vicentebolea
Copy link
Copy Markdown
Member Author

Please try what I suggested, clear env variables before spack install: env -i ... spack install

No luck

@haampie
Copy link
Copy Markdown
Member

haampie commented Jan 22, 2025

It appears that the spack autotools class reads the system aclocal.m4 if it exists

It doesn't?

Install system autoconf and pkg-config in your OpenSUSE vm

Doesn't influence it.

@haampie
Copy link
Copy Markdown
Member

haampie commented Jan 22, 2025

My guess is it's a global config.site setting libdir='{exec_prefix}/lib64'. Can you check find /usr -name config.site -type f 2>/dev/null? From other build logs shared here I see configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu 🤦 added through the CONFIG_SITE variable.

This is from the site-config package of openSUSE.

I bet you do have a variable CONFIG_SITE set then.

@haampie
Copy link
Copy Markdown
Member

haampie commented Jan 22, 2025

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.

@vicentebolea
Copy link
Copy Markdown
Member Author

Good call @haampie your changes fixed this issue thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Broken Python3 on OpenSUSE, lib-dynload not correctly linked Installation issue: python

3 participants