Skip to content

GH-108819: fix LIBDEST not honoring --with-platlibdir #133163

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

FFY00
Copy link
Member

@FFY00 FFY00 commented Apr 29, 2025

We look for the pure-Python part of the standard library in PLATSTDLIBDIR, which may not match the default LIBDIR subdir.

From getpath.py:

    ...
    STDLIB_SUBDIR = f'{platlibdir}/python{VERSION_MAJOR}.{VERSION_MINOR}{ABI_THREAD}'
    STDLIB_LANDMARKS = [f'{STDLIB_SUBDIR}/os.py', f'{STDLIB_SUBDIR}/os.pyc']
    PLATSTDLIB_LANDMARK = f'{platlibdir}/python{VERSION_MAJOR}.{VERSION_MINOR}{ABI_THREAD}/lib-dynload'
    ...

We look for the pure-Python part of the standard library in
PLATSTDLIBDIR, which may not match the default LIBDIR subdir.

From ``getpath.py``:

```python
    ...
    STDLIB_SUBDIR = f'{platlibdir}/python{VERSION_MAJOR}.{VERSION_MINOR}{ABI_THREAD}'
    STDLIB_LANDMARKS = [f'{STDLIB_SUBDIR}/os.py', f'{STDLIB_SUBDIR}/os.pyc']
    PLATSTDLIB_LANDMARK = f'{platlibdir}/python{VERSION_MAJOR}.{VERSION_MINOR}{ABI_THREAD}/lib-dynload'
    ...
```

Signed-off-by: Filipe Laíns <lains@riseup.net>
@FFY00
Copy link
Member Author

FFY00 commented Apr 29, 2025

@tfpf, can you test?

Signed-off-by: Filipe Laíns <lains@riseup.net>
@FFY00
Copy link
Member Author

FFY00 commented Apr 29, 2025

Note: Since this fix changes the pure-Python standard library installation path, it shouldn't be backported.

@FFY00 FFY00 added type-bug An unexpected behavior, bug, or error build The build process and cross-build labels Apr 29, 2025
FFY00 added 2 commits April 29, 2025 18:44
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Filipe Laíns <lains@riseup.net>
@FFY00
Copy link
Member Author

FFY00 commented Apr 29, 2025

Note: Since this fix changes the pure-Python standard library installation path, it shouldn't be backported.

We could fix old versions by patching getpath.py to use the same directory name as libdir in STDLIB_SUBDIR. If we do that, we should then also fix the stdlib path in sysconfig.

Alternatively, we could simply detect such cases, emmit a build warning, and maybe install a symlink to make stdlib available in the specified platlibdir directory. Then, based on backwards compatibility needs, distributors could choose to either manually specify the libdir directory to match platlibdir, or adjust platlibdir, whichever is correct in their scenario.

Signed-off-by: Filipe Laíns <lains@riseup.net>
@FFY00 FFY00 added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Apr 29, 2025
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @FFY00 for commit a2b43c9 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F133163%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Apr 29, 2025
@tfpf
Copy link

tfpf commented Apr 30, 2025

@tfpf, can you test?

I no longer have access to the openSUSE Tumbleweed installation on which I first found this issue, so I used Docker, as I have documented in the linked issue. I think it worked! But there's a different (possibly unrelated) error about _ctypes which intel-hm did not get, according to #131425 (comment). Did I go wrong anywhere?👇🏼

Dockerfile (updated)
FROM opensuse/tumbleweed
RUN zypper install -y gawk gcc git make zlib-devel
RUN git clone --depth 1 https://github.com/FFY00/cpython.git --branch gh-108819 --single-branch

RUN mkdir -p /usr/share/site
COPY x86_64-pc-linux-gnu /usr/share/site
ENV CONFIG_SITE=/usr/share/site/x86_64-pc-linux-gnu

WORKDIR cpython
RUN ./configure
RUN make -j16
RUN make -j16 altinstall
x86_64-pc-linux-gnu
#!/bin/sh
# Site script for configure. It is resourced via $CONFIG_SITE environment varaible.

# If user did not specify libdir, guess the correct target:
# Use lib64 for 64 bit bi-arch targets, keep the default for the rest.
if test "$libdir" = '${exec_prefix}/lib' ; then

	ac_config_site_64bit_host=NONE

	case "$host" in
	"" )
		# User did not specify host target.
		# The native platform x86_64 is a bi-arch platform.
		# Try to detect cross-compilation to inferior architecture.

		# We are trying to guess 32-bit target compilation. It's not as easy as
		# it sounds, as there is possible several intermediate combinations.
		ac_config_site_cross_to_32bit_host=NONE

		# User defined -m32 in CFLAGS or CXXFLAGS or CC or CXX:
		# (It's sufficient for 32-bit, but alone may cause mis-behavior of some checks.)
		case "$CFLAGS $CXXFLAGS $CC $CXX" in
		*-m32*)
			ac_config_site_cross_to_32bit_host=YES
			;;
		esac

		# Running with linux32:
		# (Changes detected platform, but not the toolchain target.)
		case "`/bin/uname -i`" in
		x86_64 | ppc64 | s390x | aarch64 )
			;;
		* )
			ac_config_site_cross_to_32bit_host=YES
			;;
		esac

		if test "x$ac_config_site_cross_to_32bit_host" = xNONE; then
			ac_config_site_64bit_host=YES
		fi

		;;
	*x86_64* | *ppc64* | *s390x* | *aarch64* )
		ac_config_site_64bit_host=YES
		;;
	esac

	if test "x$ac_config_site_64bit_host" = xYES; then
		libdir='${exec_prefix}/lib64'
	fi
fi

# Continue with the standard behavior of configure defined in AC_SITE_LOAD:
if test "x$prefix" != xNONE; then
	ac_site_files="$prefix/share/config.site $prefix/etc/config.site"
else
	ac_site_files="$ac_default_prefix/share/config.site $ac_default_prefix/etc/config.site"
fi

for ac_site_file in $ac_site_files
do
	case $ac_site_file in #(
	*/*) :
		 ;; #(
	*) :
		ac_site_file=./$ac_site_file ;;
esac
	if test -f "$ac_site_file" && test -r "$ac_site_file"; then
		{ printf "%s\n" "/usr/share/site/x86_64-pc-linux-gnu:${as_lineno-$LINENO}: loading site script $ac_site_file" >&5
printf "%s\n" "/usr/share/site/x86_64-pc-linux-gnu: loading site script $ac_site_file" >&6;}
		sed 's/^/| /' "$ac_site_file" >&5
		. "$ac_site_file" \
			|| { { printf "%s\n" "/usr/share/site/x86_64-pc-linux-gnu:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
printf "%s\n" "/usr/share/site/x86_64-pc-linux-gnu: error: in \`$ac_pwd':" >&2;}
as_fn_error $? "failed to load site script $ac_site_file
See \`config.log' for more details" "$LINENO" 5; }
	fi
done
$ docker build . -t gh-108819
$ docker run -it gh-108819:latest sh
sh-5.2# python3.14
Python 3.14.0a7+ (heads/gh-108819:a2b43c9, Apr 30 2025, 15:14:14) [GCC 14.2.1 20250220 [revision 9ffecde121af883b60bbe60d00425036bc873048]] on linux
Type "help", "copyright", "credits" or "license" for more information.
warning: can't use pyrepl: No module named '_ctypes'
>>>

(I suspect CONFIG_SITE is the sole culprit here—it may have nothing to do with openSUSE fundamentally.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting core review build The build process and cross-build type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants