Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
FFY00 wants to merge5 commits intopython:main
base:main
Choose a base branch
Loading
fromFFY00:gh-108819

Conversation

FFY00
Copy link
Member

@FFY00FFY00 commentedApr 29, 2025
edited by bedevere-appbot
Loading

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

Fromgetpath.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 inPLATSTDLIBDIR, 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
MemberAuthor

@tfpf, can you test?

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

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

@FFY00FFY00 added type-bugAn unexpected behavior, bug, or error buildThe build process and cross-build labelsApr 29, 2025
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Filipe Laíns <lains@riseup.net>
@FFY00
Copy link
MemberAuthor

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

We could fix old versions by patchinggetpath.py to use the same directory name aslibdir inSTDLIB_SUBDIR. If we do that, we should then also fix thestdlib path insysconfig.

Alternatively, we could simply detect such cases, emmit a build warning, and maybe install a symlink to makestdlib available in the specifiedplatlibdir directory. Then, based on backwards compatibility needs, distributors could choose to either manually specify thelibdir directory to matchplatlibdir, or adjustplatlibdir, whichever is correct in their scenario.

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

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

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-botbedevere-bot removed the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelApr 29, 2025
@tfpf
Copy link

tfpf commentedApr 30, 2025
edited
Loading

@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/tumbleweedRUN zypper install -y gawk gcc git make zlib-develRUN git clone --depth 1 https://github.com/FFY00/cpython.git --branch gh-108819 --single-branchRUN mkdir -p /usr/share/siteCOPY x86_64-pc-linux-gnu /usr/share/siteENV CONFIG_SITE=/usr/share/site/x86_64-pc-linux-gnuWORKDIR cpythonRUN ./configureRUN make -j16RUN 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.iftest"$libdir" ='${exec_prefix}/lib';thenac_config_site_64bit_host=NONEcase"$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`"inx86_64 | ppc64 | s390x | aarch64 );;* )ac_config_site_cross_to_32bit_host=YES;;esaciftest"x$ac_config_site_cross_to_32bit_host" = xNONE;thenac_config_site_64bit_host=YESfi;;*x86_64* |*ppc64* |*s390x* |*aarch64* )ac_config_site_64bit_host=YES;;esaciftest"x$ac_config_site_64bit_host" = xYES;thenlibdir='${exec_prefix}/lib64'fifi# Continue with the standard behavior of configure defined in AC_SITE_LOAD:iftest"x$prefix"!= xNONE;thenac_site_files="$prefix/share/config.site$prefix/etc/config.site"elseac_site_files="$ac_default_prefix/share/config.site$ac_default_prefix/etc/config.site"fiforac_site_filein$ac_site_filesdocase$ac_site_filein#(*/*): ;;#(*):ac_site_file=./$ac_site_file ;;esaciftest -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">&5printf"%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':">&5printf"%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_fileSee\`config.log' for more details""$LINENO" 5; }fidone
$docker build. -t gh-108819$docker run -it gh-108819:latest shsh-5.2#python3.14Python 3.14.0a7+ (heads/gh-108819:a2b43c9, Apr 30 2025, 15:14:14) [GCC 14.2.1 20250220 [revision 9ffecde121af883b60bbe60d00425036bc873048]] on linuxType "help", "copyright", "credits" or "license" for more information.warning: can't use pyrepl: No module named '_ctypes'>>>

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

FFY00 reacted with thumbs up emoji

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

@erlend-aaslanderlend-aaslandAwaiting requested review from erlend-aaslanderlend-aasland is a code owner

@corona10corona10Awaiting requested review from corona10corona10 is a code owner

Assignees
No one assigned
Labels
awaiting core reviewbuildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or error
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@FFY00@bedevere-bot@tfpf

[8]ページ先頭

©2009-2025 Movatter.jp