- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 33.3k
Closed
Labels
buildThe build process and cross-buildThe build process and cross-buildtype-featureA feature request or enhancementA feature request or enhancement
Description
Feature or enhancement
Proposal:
Summary
The current CPython build system does not produce a working multiarch layout without downstream hacks.
When --libdir=/usr/lib/<triplet> is used, extension modules are installed into a directory that is not on sys.path, unless --with-platlibdir is also set.
But setting --with-platlibdir collapses the purelib/platlib split. This leaves downstreams with two bad choices.
Observed behavior
- 
With --libdir=/usr/lib/<triplet>and no--with-platlibdir:- Pure‑Python stdlib → /usr/lib/pythonX.Y
- Extension modules → /usr/lib/<triplet>/pythonX.Y/lib-dynload
- Problem: extensions are not importable, because that path is not on sys.path.
 
- Pure‑Python stdlib → 
- 
With --with-platlibdir=<triplet>:- Both pure‑Python and extension modules collapse under /usr/lib/<triplet>/pythonX.Y
- Problem: the traditional split is lost.
 
- Both pure‑Python and extension modules collapse under 
Downstream workarounds
- Debian: patches DESTSHAREDto followLIBDEST(/usr/lib/pythonX.Y/lib-dynload).
- Flatpak freedesktop‑sdk: overrides DESTSHAREDatmake install, but this leaks the Python version into build tooling.
- Both approaches have long‑term maintenance downsides.
Why this is a problem
- Upstream CPython does not provide a working, policy‑neutral way to support multiarch layouts.
- Every downstream that cares about multiarch must carry a patch or override.
- This increases divergence and makes it harder to reason about where stdlib files live.
Proposed direction
Introduce a supported configure‑time option or default logic that:
- Keeps purelib under ${prefix}/lib/pythonX.Y
- Places extension modules under ${libdir}/pythonX.Y/lib-dynload
- Ensures both are added to sys.pathat runtime
- Updates sysconfigschemes accordingly
This would eliminate the need for downstream patches and make multiarch a first‑class citizen in CPython’s build system.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Metadata
Metadata
Assignees
Labels
buildThe build process and cross-buildThe build process and cross-buildtype-featureA feature request or enhancementA feature request or enhancement