Skip to content

[build] Multiarch: DESTSHARED placement makes stdlib extensions non-importable without downstream patching #139733

@nanonyme

Description

@nanonyme

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.
  • With --with-platlibdir=<triplet>:

    • Both pure‑Python and extension modules collapse under /usr/lib/<triplet>/pythonX.Y
    • Problem: the traditional split is lost.

Downstream workarounds

  • Debian: patches DESTSHARED to follow LIBDEST (/usr/lib/pythonX.Y/lib-dynload).
  • Flatpak freedesktop‑sdk: overrides DESTSHARED at make 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.path at runtime
  • Updates sysconfig schemes 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

No one assigned

    Labels

    buildThe build process and cross-buildtype-featureA feature request or enhancement

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions