subagent transcript

session 17f09f89 · workflow wf_6c234df9
← 17f09f89 · archive
delegated task
GOAL: port PySide6 + shiboken6 to the FreeCAD WebAssembly toolchain (static, no-dlopen, asyncify, no-pthreads) so FreeCAD's Python/PySide workbenches
▸ Magik
GOAL: port PySide6 + shiboken6 to the FreeCAD WebAssembly toolchain (static, no-dlopen, asyncify, no-pthreads) so FreeCAD's Python/PySide workbenches and macros work in the browser. This is the keystone dependency. Ground EVERYTHING in the real files — investigate, do not speculate. ESTABLISHED GROUND TRUTH (verified this session): - PySide+shiboken SOURCE: /tmp/pyside-setup (git branch 6.11, matches Qt). sources/shiboken6, sources/shiboken6_generator, sources/pyside6 (check exact dir names). Built via setup.py + coin_build_instructions.py OR raw CMake per sources/*/CMakeLists.txt + README.*.md at repo root. - HOST toolchain (x86-64 Linux): clang/llvm 21 with libclang at /usr/lib/llvm-21/lib/libclang.so (llvm-config = 21.1.8); host CPython 3.14.4 (/usr/bin/python3, headers /opt/toolchains/src/Python-3.14.4/Include); host Qt 6.11.1 at /opt/toolchains/qt/6.11.1/gcc_64. - TARGET (wasm): emscripten 4.0.12 (/opt/toolchains/emsdk); Qt 6.11.1 asyncify single-thread at /opt/toolchains/qt-asyncify/6.11.1/wasm_singlethread (QT_FEATURE_thread == -1, i.e. -no-feature-thread); wasm CPython 3.14 at /opt/toolchains/python-wasm (headers include/python3.14, lib/python3.14.zip). FreeCAD-wasm build dir: /opt/toolchains/src/freecad-gui-build (reads Qt6_DIR=qt-asyncify/.../wasm_singlethread). - FreeCAD build links Python C-extensions STATICALLY and registers them via PyImport_AppendInittab in a generated src/Main/WasmInittab*.cpp (NO dlopen on wasm). PySide bindings must follow this model: build as STATIC libs, expose PyInit_* for each module (PySide6.QtCore etc.), register in the inittab. - FreeCAD source: /home/magik6k/lcad-wasm/freecad-port/FreeCAD (branch wasm-port). It ships a PySide shim at src/Ext/PySide (a compat layer) and uses shiboken (getCppPointer/wrapInstance) e.g. in Gui/PythonWrapper.cpp. FREECAD_USE_PYSIDE/FREECAD_USE_SHIBOKEN currently OFF. - KNOWN HARD ISSUES to design around: (1) static + NO dlopen — PySide's normal build emits shared modules; must emit static + inittab. (2) Qt is -no-feature-thread — shiboken typesystem for QtCore references QThread/QMutex/etc.; those must be excluded/guarded. (3) CPython 3.14 C-API changes vs what PySide 6.11 targets. (4) asyncify + JS-exceptions (-fexceptions) flags must match FreeCAD's; libshiboken/libpyside signal dispatch must be single-thread/asyncify safe. (5) binary size (wasm is already 196 MB; each Qt binding module is tens of MB — target ONLY the modules FreeCAD needs). DELIVERABLES — do BOTH: 1. Write a thorough, concrete, execution-ready plan to /home/magik6k/lcad-wasm/pyside-port/<SLUG>/plan.md with exact commands, cmake args, file paths, patch snippets (precise enough to apply), and any test outputs you gathered. Put patch/new-file contents as separate files in that dir. If you build/test something, capture the real output. 2. Return the structured summary (schema). Depth goes in plan.md; keep summary fields tight. Token cost is not a concern — be exhaustive and correct. Prefer running real commands (grep, ls, cmake --help, small test builds) over speculation. === YOUR SCOPE: CPython 3.14 C-API compatibility for shiboken/PySide 6.11 (slug: py314-compat) === Does shiboken6/PySide6 6.11 build against CPython 3.14? Py 3.14 changed/removed C-API (e.g. structmember.h moves, _PyObject internals, PyType_Spec changes, Py_TRASHCAN, tp_ macros). Grep sources/shiboken6/libshiboken + sources/pyside6/libpyside for likely-affected C-API. Check the pyside-setup git branch 6.11 for whether it already claims 3.14 support (build_scripts, README, setup.py python_requires). Cross-reference with our host Python 3.14.4 headers (/opt/toolchains/src/Python-3.14.4/Include). List the C-API breakages and the patches. Try compiling one libshiboken .cpp against Python 3.14 headers to surface real errors. Create /home/magik6k/lcad-wasm/pyside-port/py314-compat/ and write plan.md (required) + any patches. Return the schema with deliverableFile=/home/magik6k/lcad-wasm/pyside-port/py314-compat/plan.md.
Fable
thinking
I'm going to start exploring the pyside-setup source code and Python 3.14 headers to understand what's happening, then work through several angles in parallel.
Fable
I'll investigate the real sources. Let me start by exploring the structure.
Fable
⚙ Bash {"command": "ls /tmp/pyside-setup/sources/ 2>/dev/null; echo \"---shiboken6---\"; ls /tmp/pyside-setup/sources/shiboken6/ 2>/dev/null; echo \"---libshiboken---\"; ls /tmp/pyside-setup/sources/shiboken6/libshiboken/ 2>/dev/null; echo \"---li…
tool result
pyside-tools
pyside6
shiboken6
shiboken6_generator
---shiboken6---
AUTHORS
CMakeLists.txt
COPYING
COPYING.libsample
COPYING.libshiboken
Doxyfile
cmake
cmake_uninstall.cmake
config.tests
data
doc
generatorrunnerconfig.h.in
generatorrunnermacros.h
icecc.cmake
libshiboken
shiboken_version.py
shibokenmodule
tests
---libshiboken---
CMakeLists.txt
autodecref.h
basewrapper.cpp
basewrapper.h
basewrapper_p.h
bindingmanager.cpp
bindingmanager.h
bufferprocs_py37.cpp
bufferprocs_py37.h
debugfreehook.cpp
deb  …[truncated]
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup && git branch 2>/dev/null; git log --oneline -3 2>/dev/null; echo \"---python_requires---\"; grep -rn \"python_requires\\|3.14\\|3, 14\\|3,14\" setup.py build_scripts/ 2>/dev/null | head -40", "description"…
tool result
* 6.11
cc7c88a Type hints: Fix Stacked currentWidget return type hint
---python_requires---
build_scripts/config.py:86:        self.setup_kwargs['python_requires'] = _pyproject_data["requires-python"]
Fable
⚙ Bash {"command": "ls /opt/toolchains/src/Python-3.14.4/Include/ 2>/dev/null | head; echo \"---structmember---\"; ls /opt/toolchains/src/Python-3.14.4/Include/structmember.h /opt/toolchains/src/Python-3.14.4/Include/cpython/ 2>/dev/null; echo \"=…
tool result
Python.h
README.rst
abstract.h
audit.h
bltinmodule.h
boolobject.h
bytearrayobject.h
bytesobject.h
ceval.h
codecs.h
---structmember---
/opt/toolchains/src/Python-3.14.4/Include/structmember.h

/opt/toolchains/src/Python-3.14.4/Include/cpython/:
abstract.h
audit.h
bytearrayobject.h
bytesobject.h
cellobject.h
ceval.h
classobject.h
code.h
compile.h
complexobject.h
context.h
critical_section.h
descrobject.h
dictobject.h
fileobject.h
fileutils.h
floatobject.h
frameobject.h
funcobject.h
genobject.h
imp  …[truncated]
Fable
thinking
I need to verify that structmember.h is still available in Python 3.14, then cross-check the Python version requirements in pyproject against what PySide 6.11 supports, and examine how the C-API is being used.
Fable
Let me check pyside's claimed Python support and grep for likely-affected C-API.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup; echo \"===requires-python===\"; grep -rn \"requires-python\\|Programming Language :: Python\" pyproject.toml *.toml 2>/dev/null; echo \"===version files===\"; cat sources/shiboken6/shiboken_version.py 2>/d…
tool result
===requires-python===
===version files===
# Copyright (C) 2022 The Qt Company Ltd.
# SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only
from __future__ import annotations

major_version = "@shiboken_MAJOR_VERSION@"
minor_version = "@shiboken_MINOR_VERSION@"
patch_version = "@shiboken_MICRO_VERSION@"

# For example: "a", "b", "rc"
# (which means "alpha", "beta", "release candidate").
===coin/testing supported py===
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources; echo \"=== structmember usage ===\"; grep -rn \"structmember.h\\|T_OBJECT\\|T_INT\\|PyMemberDef\" shiboken6/libshiboken pyside6/libpyside 2>/dev/null | head; echo \"=== Py_TRASHCAN ===\"; grep -rn …
tool result
=== structmember usage ===
shiboken6/libshiboken/sbkenum.cpp:372:    bool useIntInheritance = Enum::enumOption & Enum::ENOPT_INHERIT_INT;
shiboken6/libshiboken/sbkpython.h:22:#  include <structmember.h>
shiboken6/libshiboken/sbkpython.h:31:#  include <structmember.h>
shiboken6/libshiboken/sbkenum.h:37:    ENOPT_INHERIT_INT     = 0x02,
shiboken6/libshiboken/pep384impl.cpp:49:static PyMemberDef probe_members[] = {
shiboken6/libshiboken/pep384impl.h:91:    struct PyMemberDef *tp_members;
shiboken6/  …[truncated]
Fable
thinking
I need to check the pyproject.toml for the requires-python setting, but the grep came up empty. Looking at the actual files, I can see that sbktypefactory.cpp is directly accessing type internals through tp_ member manipulation, which is a key issue. The Python 3.14 changes are substantial, so I need to examine the critical files like basewrapper.cpp, basewrapper_p.h, and pep384impl.cpp to understand the full scope of C-API usage that's affected.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup; find . -maxdepth 2 -name \"pyproject.toml\" -o -maxdepth 2 -name \"setup.py\" | head; echo \"===root pyproject===\"; cat pyproject.toml 2>/dev/null | head -40; echo \"=== shiboken pyproject ===\"; find . -…
tool result
./setup.py
===root pyproject===
=== shiboken pyproject ===
./wheel_artifacts/pyproject.toml.base
./examples/quickcontrols/gallery/pyproject.toml
./sources/pyside6/doc/tutorials/qmlapp/pyproject.toml
./examples/tutorials/drumpad/final_project/Python/pyproject.toml
./sources/pyside6/tests/tools/pyside6-project/example_project/pyproject.toml
./sources/pyside6/tests/tools/pyside6-project/invalid_pyproject/pyproject.toml
./sources/pyside6/tests/tools/pyside6-project/existing_pyproject_toml/pyproject.  …[truncated]
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup; for f in $(find . -name \"pyproject.toml*\"); do echo \"=== $f ===\"; grep -n \"requires-python\\|Python :: 3\" \"$f\"; done", "description": "Grep requires-python across pyproject files"}
tool result
Exit code 1
=== ./wheel_artifacts/pyproject.toml.base ===
13:requires-python = ">=3.10, <3.15"
31:    "Programming Language :: Python :: 3",
32:    "Programming Language :: Python :: 3.10",
33:    "Programming Language :: Python :: 3.11",
34:    "Programming Language :: Python :: 3.12",
35:    "Programming Language :: Python :: 3.13",
36:    "Programming Language :: Python :: 3.14",
=== ./examples/quickcontrols/gallery/pyproject.toml ===
=== ./examples/tutorials/drumpad/final_project/Python/pypr  …[truncated]
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources; echo \"=== more risky internals ===\"; grep -rn \"tp_dict\\|tp_mro\\|tp_bases\\|tp_subclasses\\|tp_getattro\\|tp_setattro\\|ht_type\\|_PyObject_GetDictPtr\\|_PyObject_MakeTpCall\\|tp_dictoffset\\|t…
tool result
=== more risky internals ===
shiboken6/libshiboken/sbkenum.cpp:133:    auto *mro = reinterpret_cast<PyTypeObject *>(ob_type)->tp_mro;
shiboken6/libshiboken/sbktypefactory.cpp:70:            base->ob_type = meta;
shiboken6/libshiboken/sbktypefactory.cpp:107:        base->ob_type = &PyType_Type;
shiboken6/libshiboken/sbktypefactory.cpp:161:        type->tp_dictoffset = dictoffset;
shiboken6/libshiboken/sbktypefactory.cpp:163:        type->tp_weaklistoffset = weaklistoffset;
shiboken6/libshiboken/s  …[truncated]
Fable
thinking
I'm noticing that PySide 6.11 officially supports Python 3.14 according to the pyproject.toml configuration, which means shiboken6 and PySide6 are already building against CPython 3.14. Now I need to check if the codebase includes the necessary version guards for 3.14, specifically looking for the hex representation `0x030E` and related Python version checks.
Fable
PySide 6.11 declares `requires-python = ">=3.10, <3.15"` with a 3.14 classifier. Let me verify actual 3.14 code guards exist.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources; echo \"=== 3.14 hex guards (0x030E) ===\"; grep -rn \"0x030E\\|0x030e\\|0x030D\\|0x030d\\|0x030C\" shiboken6/libshiboken pyside6/libpyside 2>/dev/null | head -40; echo; echo \"=== PY_VERSION_HEX to…
tool result
=== 3.14 hex guards (0x030E) ===
shiboken6/libshiboken/sbktypefactory.cpp:96:#if !defined(Py_LIMITED_API) && PY_VERSION_HEX >= 0x030C0000
shiboken6/libshiboken/pep384impl.cpp:316:    if (_PepRuntimeVersion() < 0x030C00) {
shiboken6/libshiboken/pep384impl.cpp:328:    if (_PepRuntimeVersion() < 0x030C00) {
shiboken6/libshiboken/pep384impl.cpp:338:    return _PepRuntimeVersion() < 0x030C00
shiboken6/libshiboken/pep384impl.cpp:893:#if !defined(Py_LIMITED_API) && PY_VERSION_HEX >= 0x030C0000
shiboken  …[truncated]
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources; grep -rn \"PY_VERSION_HEX\" shiboken6/libshiboken pyside6/libpyside 2>/dev/null | grep -iv \"0x0308\\|0x0309\\|0x030A\\|0x030a\\|0x0307\" | head -50", "description": "List PY_VERSION_HEX guards exc…
tool result
shiboken6/libshiboken/sbkfeature_base.cpp:107:#if PY_VERSION_HEX >= 0x030C0000 && !Py_LIMITED_API
shiboken6/libshiboken/sbkfeature_base.cpp:168:#if PY_VERSION_HEX >= 0x030B0000 && !Py_LIMITED_API
shiboken6/libshiboken/sbktypefactory.cpp:96:#if !defined(Py_LIMITED_API) && PY_VERSION_HEX >= 0x030C0000
shiboken6/libshiboken/pep384impl.cpp:717:#if !defined(PYPY_VERSION) && ((!defined(Py_LIMITED_API) && PY_VERSION_HEX >= 0x030B0000) || (defined(Py_LIMITED_API) && Py_LIMITED_API >= 0x030B0000))
shibok  …[truncated]
Fable
thinking
I'm seeing explicit Python 3.14 runtime guards in the source files, which confirms PySide 6.11 already has support for it. Now I need to verify this by attempting to compile a libshiboken C++ file against Python 3.14 headers to see if there are any actual compatibility issues.
Fable
The source has explicit `0x030E00` (3.14) runtime guards. Now let me attempt a real compile against Python 3.14 headers.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources/shiboken6/libshiboken; echo \"=== includes needed by a simple TU ===\"; head -40 sbkstring.cpp; echo \"=== generated headers referenced? ===\"; grep -rln \"sbkversion.h\\|shibokenmacros.h\" *.cpp | …
tool result
=== includes needed by a simple TU ===
// Copyright (C) 2019 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only
// Qt-Security score:significant reason:default

#include "sbkstring.h"
#include "sbkpep.h"
#include "sbkenum.h"
#include "sbkstaticstrings_p.h"
#include "autodecref.h"

#include <cstring>
#include <cctype>

namespace Shiboken::String
{

// PYSIDE-795: Redirecting PySequence to Iterable
bool checkIterable(PyObject *  …[truncated]
Fable
thinking
I need to figure out what sbkversion.h is and whether I can generate it or create a stub. Let me try compiling sbkstring.cpp to see what actually breaks, then I'll set up the include paths and compile against Python 3.14 using the host clang compiler.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources/shiboken6/libshiboken; grep -rln \"sbkversion.h\" *.h *.cpp; echo \"=== create sbkversion.h stub if needed ===\"; cat sbkversion.h.in", "description": "Find sbkversion.h usage and template"}
tool result
sbkpep.h
=== create sbkversion.h stub if needed ===
// Copyright (C) 2016 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only

#ifndef SBKVERSION_H
#define SBKVERSION_H

#define SHIBOKEN_VERSION "@shiboken_MAJOR_VERSION@.@shiboken_MINOR_VERSION@.@shiboken_MICRO_VERSION@"
#define SHIBOKEN_MAJOR_VERSION @shiboken_MAJOR_VERSION@
#define SHIBOKEN_MINOR_VERSION @shiboken_MINOR_VERSION@
#define SHIBOKEN_MICRO_VERSION @shiboken_MICRO  …[truncated]
Fable
⚙ Bash {"command": "mkdir -p /tmp/sbktest/gen\ncat > /tmp/sbktest/gen/sbkversion.h <<'EOF'\n#ifndef SBKVERSION_H\n#define SBKVERSION_H\n#define SHIBOKEN_VERSION \"6.11.0\"\n#define SHIBOKEN_MAJOR_VERSION 6\n#define SHIBOKEN_MINOR_VERSION 11\n#defi…
tool result
/opt/toolchains/src/Python-3.14.4/PC/pyconfig.h
/opt/toolchains/src/Python-3.14.4/cross-build/build/pyconfig.h
/opt/toolchains/src/Python-3.14.4/cross-build/wasm32-emscripten/build/python/pyconfig.h
/opt/toolchains/src/Python-3.14.4/Apple/iOS/Resources/pyconfig.h
=== clang version ===
/bin/bash: line 26: clang: command not found
Fable
thinking
Looking for clang via the llvm-21 path, and I need pyconfig.h for the host compile test. There's a native build version in cross-build/build/pyconfig.h, but the simplest approach is to check if there's an installed Python 3.14 with dev headers—I see /usr/bin/python3 is 3.14.4, so I'll use sysconfig to get its include directory.
Fable
⚙ Bash {"command": "ls /usr/lib/llvm-21/bin/clang* 2>/dev/null; echo \"---\"; /usr/bin/python3 -c \"import sysconfig; print(sysconfig.get_path('include')); print(sysconfig.get_config_var('CONFINCLUDEPY'))\"; echo \"--- check pyconfig in host inclu…
tool result
Exit code 2
---
/usr/include/python3.14
/usr/include/python3.14
--- check pyconfig in host include ---
Fable
⚙ Bash {"command": "ls /usr/include/python3.14/ 2>/dev/null | head; echo \"=== find any clang ===\"; ls /usr/lib/llvm-21/bin/ 2>/dev/null | grep -i clang; which gcc g++ 2>/dev/null; echo \"=== full py 3.14 headers install? ===\"; ls /usr/include/p…
tool result
Exit code 2
=== find any clang ===
/usr/bin/gcc
/usr/bin/g++
=== full py 3.14 headers install? ===
Fable
thinking
The /usr/include/python3.14 directory exists but is empty—the ls command failed because Python.h isn't there, meaning the dev headers aren't installed on the host system. The actual headers are in the source tree's Include directory, but I need to figure out where pyconfig.h is coming from, likely the cross-build or native build configuration.

For the compiler, g++ is available and should work fine for testing C-API compatibility, though I should check if clang is accessible since llvm-21 exists in the system.
Fable
⚙ Bash {"command": "ls /usr/lib/llvm-21/bin/ | head -30; echo \"=== emsdk clang ===\"; ls /opt/toolchains/emsdk/upstream/bin/clang* 2>/dev/null | head", "description": "List llvm-21 bin and emsdk clang"}
tool result
FileCheck
UnicodeNameMappingGenerator
bugpoint
count
dsymutil
lit
llc
lli
lli-child-target
llvm-PerfectShuffle
llvm-addr2line
llvm-ar
llvm-as
llvm-bcanalyzer
llvm-bitcode-strip
llvm-c-test
llvm-cat
llvm-cfi-verify
llvm-cgdata
llvm-config
llvm-cov
llvm-ctxprof-util
llvm-cvtres
llvm-cxxdump
llvm-cxxfilt
llvm-cxxmap
llvm-debuginfo-analyzer
llvm-debuginfod
llvm-debuginfod-find
llvm-diff
=== emsdk clang ===
/opt/toolchains/emsdk/upstream/bin/clang
/opt/toolchains/emsdk/upstream/bin/clang++
/opt/toolc  …[truncated]
Fable
thinking
I'll use g++ for the host compile test since it's the simplest way to surface C-API errors. I'm planning to compile a few key files—sbkstring.cpp, sbkfeature_base.cpp (which has the 3.14 opcode analysis), and sbkmodule.cpp—and I need to set up the include paths to point to libshiboken's own directory, the generated files directory for sbkversion.h, Python's Include directory, and the pyconfig.h location.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources/shiboken6/libshiboken\nPYINC=/opt/toolchains/src/Python-3.14.4/Include\nPYCONF=/opt/toolchains/src/Python-3.14.4/cross-build/build\nGEN=/tmp/sbktest/gen\nLIB=$(pwd)\nfor f in sbkstring.cpp helper.cp…
tool result
======== sbkstring.cpp ========
exit: 0
======== helper.cpp ========
exit: 0
======== sbkfeature_base.cpp ========
exit: 0
======== sbkmodule.cpp ========
exit: 0
Fable
thinking
I'm testing the most complex modules that dig into Python's internal type structures—the ones that manipulate type offsets, trash can macros, and PEP 384 limited API shims—to make sure they all compile cleanly against Python 3.14 headers, then running a full compilation pass.
Fable
All four clean. Let me compile the internals-heavy ones and the whole set.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources/shiboken6/libshiboken\nPYINC=/opt/toolchains/src/Python-3.14.4/Include\nPYCONF=/opt/toolchains/src/Python-3.14.4/cross-build/build\nGEN=/tmp/sbktest/gen; LIB=$(pwd)\nfail=0\nfor f in $(ls *.cpp); do…
tool result
ok: basewrapper.cpp
ok: bindingmanager.cpp
ok: bufferprocs_py37.cpp
ok: debugfreehook.cpp
ok: gilstate.cpp
ok: helper.cpp
ok: pep384ext.cpp
ok: pep384impl.cpp
ok: sbkarrayconverter.cpp
ok: sbkbindingutils.cpp
ok: sbkcontainer.cpp
ok: sbkconverter.cpp
ok: sbkcppstring.cpp
==== FAIL: sbkcpptonumpy.cpp ====
sbkcpptonumpy.cpp:46:1: error: 'PyObject' does not name a type
   46 | PyObject *createByteArray1(Py_ssize_t, const uint8_t *)
      | ^~~~~~~~
sbkcpptonumpy.cpp:51:1: error: 'PyObject' does not  …[truncated]
Fable
thinking
The numpy-related compilation failures are just missing C headers in the include path, not a Python 3.14 compatibility issue—they're guarded by HAVE_NUMPY and only built when numpy is available, which FreeCAD likely doesn't need for shiboken anyway. So these aren't actual blockers for the port.

The core internal files all compile cleanly against Python 3.14.4, so now I should verify the numpy failures are purely header-related, check if the signature module compiles, and see what's needed for libpyside (though Qt headers might make that harder to test).
Fable
The numpy failures are just missing numpy headers, not a 3.14 issue. Let me confirm numpy conditionality and test the signature module.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources/shiboken6/libshiboken\necho \"=== numpy guard in CMakeLists ===\"; grep -n -i \"numpy\\|NUMPY\" CMakeLists.txt | head -20\necho \"=== signature dir ===\"; ls signature/\nPYINC=/opt/toolchains/src/Py…
tool result
=== numpy guard in CMakeLists ===
75:sbkcppstring.cpp sbkcppstring.h sbkcpptonumpy.h
81:sbknumpy.cpp sbknumpycheck.h
82:sbknumpyview.h
121:if (NOT "${NUMPY_INCLUDE_DIR}" STREQUAL "")
122:    message(STATUS "NUMPY_INCLUDE_DIR: " ${NUMPY_INCLUDE_DIR})
123:    target_include_directories(libshiboken PRIVATE ${NUMPY_INCLUDE_DIR})
124:    target_compile_definitions(libshiboken PRIVATE -DHAVE_NUMPY
127:    message(STATUS "NUMPY not found")
174:        sbkcpptonumpy.h
182:        sbknumpycheck.h
183:     …[truncated]
Fable
thinking
The signature_globals.cpp compilation failure stems from embed/signature_inc.h being a generated file that's created during the build process, not an actual Python 3.14 compatibility issue. The numpy-related files only compile when the appropriate build flags are set, and those are optional dependencies that can be disabled. So shiboken6 6.11's libshiboken actually compiles without problems against CPython 3.14.4.

Let me verify the numpy files aren't a 3.14 issue by checking if numpy headers are available on this system and testing compilation with them present.
Fable
Let me confirm the numpy files compile when numpy headers are present (proving they're not 3.14 issues).
Fable
⚙ Bash {"command": "NPINC=$(/usr/bin/python3 -c \"import numpy;print(numpy.get_include())\" 2>/dev/null); echo \"numpy inc=$NPINC\"\ncd /tmp/pyside-setup/sources/shiboken6/libshiboken\nPYINC=/opt/toolchains/src/Python-3.14.4/Include\nPYCONF=/opt/t…
tool result
numpy inc=
numpy not installed on host; failures were purely missing NPY headers (HAVE_NUMPY off by default)
Fable
thinking
The numpy compilation failures are just missing headers since numpy support is disabled by default and not needed for FreeCAD's shiboken integration. Now I'm diving into the 3.14-specific opcode handling in the codebase to understand what it actually does.
Fable
All confirmed: the only failures are missing numpy/generated headers, orthogonal to 3.14. Let me examine the actual 3.14-specific code paths to document them.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources/shiboken6/libshiboken; sed -n '95,145p' sbkfeature_base.cpp; echo \"=== sbkmodule 295-320 ===\"; sed -n '295,320p' sbkmodule.cpp", "description": "Read 3.14 opcode/module code paths"}
tool result
        fprintf(stdout, "\n%s BEGIN no frame END\n\n", marker);
    } else {
        AutoDecRef f_lasti(PyObject_GetAttr(frame, _f_lasti));
        AutoDecRef f_lineno(PyObject_GetAttr(frame, _f_lineno));
        AutoDecRef f_code(PyObject_GetAttr(frame, _f_code));
        AutoDecRef co_filename(PyObject_GetAttr(f_code, _co_filename));
        long line = PyLong_AsLong(f_lineno);
        const char *fname = String::toCString(co_filename);
        fprintf(stdout, "\n%s BEGIN line=%ld %s\n", marke  …[truncated]
Fable
thinking
I'm looking at the critical parts of shiboken's feature detection system—it parses Python bytecode opcodes to identify `from __feature__ import` statements and wildcard imports, relying on hardcoded opcode values that vary by Python version. The good news is that the 3.14 opcodes are already defined in the codebase, so I need to verify those values are correct.

Let me check the actual opcode definitions in Python 3.14.4 using the dis module to confirm they match what's already in the source.
Fable
These hardcoded 3.14 opcodes are the fragile part. Let me verify them against the actual Python 3.14.4 opcode values.
Fable
⚙ Bash {"command": "/usr/bin/python3 - <<'EOF'\nimport opcode, dis\no = opcode.opmap\nwant = ['LOAD_ATTR','CALL','PUSH_NULL','LOAD_CONST','IMPORT_NAME']\nsrc = {'LOAD_ATTR':80,'CALL':52,'PUSH_NULL':33,'LOAD_CONST':82,'IMPORT_NAME':73}\nimport sys\…
tool result
python 3.14.4
LOAD_ATTR    actual=80  shiboken_src=80  OK
CALL         actual=52  shiboken_src=52  OK
PUSH_NULL    actual=33  shiboken_src=33  OK
LOAD_CONST   actual=82  shiboken_src=82  OK
IMPORT_NAME  actual=73  shiboken_src=73  OK
Fable
thinking
The opcodes all match Python 3.14.4 perfectly, which confirms shiboken 6.11 has full Python 3.14 support. Now I'm digging into libpyside to check for any version-specific concerns—I'll search for C-API issues and version guards there, plus examine the shiboken generator more closely.
Fable
All 3.14 opcodes match exactly. Now let me check libpyside for 3.14 concerns and any use of removed/deprecated C-API.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources/pyside6/libpyside\necho \"=== version guards ===\"; grep -rn \"PY_VERSION_HEX\\|0x030E\\|0x030D\\|0x030C\" *.cpp *.h 2>/dev/null\necho \"=== potentially removed/changed C-API in 3.14 ===\"\ngrep -rn…
tool result
=== version guards ===
=== potentially removed/changed C-API in 3.14 ===
pysidesignal.cpp:104:    return std::strcmp(PepType_GetFullyQualifiedNameStr(Py_TYPE(o)), typeName.constData()) == 0;
pysidesignal.cpp:455:    } else if (std::strcmp(PepType_GetFullyQualifiedNameStr(Py_TYPE(slot)), "compiled_function") == 0) {
pysidesignal.cpp:547:        && qstrcmp(PepType_GetFullyQualifiedNameStr(Py_TYPE(type)), "ConnectionType") == 0) {
pysidesignal.cpp:558:    if (Py_TYPE(slot) == PySideSignalInstance_T  …[truncated]
Fable
thinking
Libpyside doesn't need version guards since it relies on shiboken's pep384impl helpers to handle version differences centrally, and PyDict_GetItem is still available in Python 3.14 even though it's soft-deprecated. The version-specific logic is abstracted away in libshiboken, so libpyside doesn't have direct 3.14 concerns.

I should verify a couple things: that PyDict_GetItem still exists in the 3.14 headers as a borrowed reference, and check whether shiboken uses the old T_ macros or the newer Py_T_ constants from structmember.h, since those moved in 3.14.
Fable
⚙ Bash {"command": "cd /tmp/pyside-setup/sources\necho \"=== structmember T_ constant usage (deprecated in 3.14, still present) ===\"\ngrep -rn \"\\bT_OBJECT\\b\\|\\bT_INT\\b\\|\\bT_CHAR\\b\\|\\bT_STRING\\b\\|\\bT_PYSSIZET\\b\\|Py_T_OBJECT\\|Py_RE…
tool result
=== structmember T_ constant usage (deprecated in 3.14, still present) ===
=== is structmember.h still shipped in 3.14? ===
-rw-r--r-- 1 agent agent 1646 Apr  7 15:13 /opt/toolchains/src/Python-3.14.4/Include/structmember.h
#ifndef Py_STRUCTMEMBER_H
#define Py_STRUCTMEMBER_H
#ifdef __cplusplus
extern "C" {
#endif


/* Interface to map C struct members to Python object attributes
 *
 * This header is deprecated: new code should not use stuff from here.
 * New definitions are in descrobject.h.
 *
  …[truncated]
Fable
thinking
Structmember.h is still included in 3.14 for backward compatibility, and shiboken doesn't directly reference the bare T_ constants—it just includes the header defensively in sbkpython.h. PyDict_GetItem remains available too. Based on my verification, shiboken6/PySide6 6.11 already has full CPython 3.14 support without needing any C-API patches, though I should keep an eye on the wasm/emscripten build and numpy considerations.

Now I'm thinking about the emscripten compilation side—clang-22 will be compiling against the wasm Python 3.14 headers, which might have different pyconfig settings. Let me do a quick syntax check by compiling a couple of key files like basewrapper.cpp and sbktypefacto  …
Fable
structmember.h still ships (deprecated), shiboken doesn't use bare T_ constants. Let me do one final check: compile key files with the actual emscripten clang against the wasm Python 3.14 headers.
Fable
⚙ Bash {"command": "source /opt/toolchains/emsdk/emsdk_env.sh 2>/dev/null\nWPYINC=/opt/toolchains/python-wasm/include/python3.14\nls $WPYINC/Python.h $WPYINC/pyconfig.h 2>/dev/null\ncd /tmp/pyside-setup/sources/shiboken6/libshiboken\nGEN=/tmp/sbkt…
tool result
/opt/toolchains/python-wasm/include/python3.14/Python.h
/opt/toolchains/python-wasm/include/python3.14/pyconfig.h
ok(emcc/wasm-py3.14): basewrapper.cpp
ok(emcc/wasm-py3.14): sbktypefactory.cpp
ok(emcc/wasm-py3.14): pep384impl.cpp
ok(emcc/wasm-py3.14): sbkfeature_base.cpp
ok(emcc/wasm-py3.14): sbkmodule.cpp
Fable
thinking
The libshiboken internals compile cleanly with emscripten against the actual wasm CPython headers, which confirms everything is working correctly. Now I'm going to do a full compilation of the complete libshiboken set with emcc and then document the plan.
Fable
All internals-heavy files compile with emscripten against wasm Python 3.14. Let me run the full libshiboken set under emcc, then write the plan.
Fable
⚙ Bash {"command": "source /opt/toolchains/emsdk/emsdk_env.sh 2>/dev/null\nWPYINC=/opt/toolchains/python-wasm/include/python3.14\ncd /tmp/pyside-setup/sources/shiboken6/libshiboken\nGEN=/tmp/sbktest/gen; LIB=$(pwd); fail=0; okc=0\nfor f in $(ls *.…
tool result
skip(numpy-optional): sbkcpptonumpy.cpp
skip(numpy-optional): sbknumpy.cpp
skip(numpy-optional): sbknumpyarrayconverter.cpp
skip(numpy-optional): sbknumpyview.cpp
emcc: 24 TUs OK, fail=0
Fable
All 24 non-numpy libshiboken TUs compile clean under emscripten against wasm Python 3.14. Let me write the deliverable.
Fable
⚙ Bash {"command": "mkdir -p /home/magik6k/lcad-wasm/pyside-port/py314-compat", "description": "Create deliverable dir"}
tool result
(Bash completed with no output)
Fable
⚙ Write {"file_path": "/home/magik6k/lcad-wasm/pyside-port/py314-compat/plan.md", "content": "# CPython 3.14 C-API compatibility for shiboken6 / PySide6 6.11\n\n**Scope:** Does shiboken6/PySide6 6.11 build against CPython 3.14? What C-API breakages…
tool result
File created successfully at: /home/magik6k/lcad-wasm/pyside-port/py314-compat/plan.md (file state is current in your context — no need to Read it back)
Fable
Now the reproducible verification script, opcode check, and the sbkversion.h stub as artifacts.
Fable
⚙ Write {"file_path": "/home/magik6k/lcad-wasm/pyside-port/py314-compat/sbkversion.h", "content": "/* Stub of the CMake-generated sbkversion.h (from libshiboken/sbkversion.h.in)\n * used only for standalone syntax-compile tests against Python 3.14.…
tool result
File created successfully at: /home/magik6k/lcad-wasm/pyside-port/py314-compat/sbkversion.h (file state is current in your context — no need to Read it back)
Fable
⚙ Write {"file_path": "/home/magik6k/lcad-wasm/pyside-port/py314-compat/test_opcodes.py", "content": "#!/usr/bin/env python3\n\"\"\"Verify shiboken 6.11's hardcoded 3.14 bytecode opcodes match the running Python.\n\nshiboken's feature-select / impo…
tool result
File created successfully at: /home/magik6k/lcad-wasm/pyside-port/py314-compat/test_opcodes.py (file state is current in your context — no need to Read it back)
Fable
⚙ Write {"file_path": "/home/magik6k/lcad-wasm/pyside-port/py314-compat/verify.sh", "content": "#!/usr/bin/env bash\n# Reproduce the Python 3.14 C-API compatibility evidence for shiboken6 6.11.\n# Exits non-zero if any non-numpy libshiboken TU fail…
tool result
File created successfully at: /home/magik6k/lcad-wasm/pyside-port/py314-compat/verify.sh (file state is current in your context — no need to Read it back)
Fable
Let me run the verify script end-to-end to confirm the artifact reproduces.
Fable
⚙ Bash {"command": "chmod +x /home/magik6k/lcad-wasm/pyside-port/py314-compat/verify.sh\nbash /home/magik6k/lcad-wasm/pyside-port/py314-compat/verify.sh 2>&1 | tail -30", "description": "Run the reproducible verify script"}
tool result
==========================================================
[1] Opcode check against host Python 3.14
==========================================================
python 3.14.4
LOAD_ATTR    actual=80  shiboken_src=80  OK
CALL         actual=52  shiboken_src=52  OK
PUSH_NULL    actual=33  shiboken_src=33  OK
LOAD_CONST   actual=82  shiboken_src=82  OK
IMPORT_NAME  actual=73  shiboken_src=73  OK

PASS: all opcodes match.

==========================================================
[2] Host g++ syntax-  …[truncated]
Fable
The verify script reproduces cleanly end-to-end. My investigation is complete.
Fable
⚙ StructuredOutput {"__unparsedToolInput": {"raw": "{\"slug\": \"py314-compat\", \"title\": \"CPython 3.14 C-API compatibility for shiboken6/PySide6 6.11\", \"verdict\": \"COMPATIBLE — no patches needed. PySide/shiboken 6.11 already officially targets CPython…
tool result
<tool_use_error>InputValidationError: StructuredOutput was called with input that could not be parsed as JSON.
You sent (first 200 of 2218 bytes): {"slug": "py314-compat", "title": "CPython 3.14 C-API compatibility for shiboken6/PySide6 6.11", "verdict": "COMPATIBLE — no patches needed. PySide/shiboken 6.11 already officially targets CPython 3.1
Common causes: unescaped backslashes in file paths (use / or \\), unescaped control characters, or truncated output. Retry with valid JSON.</tool_use_er  …[truncated]
Fable
⚙ StructuredOutput {"slug": "py314-compat", "title": "CPython 3.14 C-API compatibility for shiboken6/PySide6 6.11", "verdict": "COMPATIBLE — no patches needed. PySide/shiboken 6.11 already officially targets CPython 3.14 (wheel_artifacts/pyproject.toml.base d…
tool result
Structured output provided successfully