# PLUGIN COMPATIBILITY — v2.0.1 binaries vs the 407 image

All numbers in this file were re-checked directly from the binaries and the
extracted 407 sysroot with `aarch64-linux-gnu-readelf -d/-V` on
2026-08-30. The previously reported 2.38 / 2.43 figures were **independently
reconfirmed** against the v2.0.1 binaries themselves (brief §22 rule).

## 1. The 407 libc floor — VERIFIED

- `libc6 2.36-9+deb12u10` at `/usr/lib/aarch64-linux-gnu/libc.so.6`.
- Highest exported symbol version: **GLIBC_2.36** (plus GLIBC_ABI_DT_RELR,
  GLIBC_PRIVATE — internals, not a compatibility floor).
- `libm.so.6` (separate file on 407): highest GLIBC_2.35.
- Loader: `/usr/lib/ld-linux-aarch64.so.1` → `aarch64-linux-gnu/ld-linux-aarch64.so.1`,
  ELF64 AArch64, OSABI GNU/Linux. Highest exported GLIBC_2.35.
- Highest exported GLIBC symbol on the image: **GLIBC_2.36**.

## 2. Old v2.0.1 binaries (container-cross build, commit 857dbf8) — VERIFIED

| Plugin | DT_NEEDED | Highest GLIBC requirement | Verdict on 407 |
|---|---|---|---|
| performance_buffer.so  | libm.so.6, libc.so.6 | **GLIBC_2.38** (`fmod@GLIBC_2.38`) | INCOMPATIBLE |
| performance_granular.so| libm.so.6, libc.so.6 | **GLIBC_2.38** (`fmod@GLIBC_2.38`) | INCOMPATIBLE |
| performance_spectral.so| libm.so.6, libc.so.6, ld-linux-aarch64.so.1 | **GLIBC_2.43** | INCOMPATIBLE |
| performance_space.so   | libm.so.6, libc.so.6, ld-linux-aarch64.so.1 | **GLIBC_2.43** (`sqrtf`/`atan2f@GLIBC_2.43`) | INCOMPATIBLE |

Root cause (established in the v2.0.1 audit, reconfirmed here): the build
machine's glibc headers bake versioned-symbol requirements
(`fmod@GLIBC_2.38`, `sqrtf/atan2f@GLIBC_2.43`) at compile/link time;
`-fno-builtin` does not remove them. Requirements 2.38 / 2.43 > provided 2.36.

## 3. Rebuilt binaries (407 sysroot, commit 857dbf8 sources) — 407-SYSROOT COMPILED

Build config: `SYSROOT_BUILD.md` §4. `--sysroot` + 407's own headers and
407's own shared libs → symbol versions come from the 407 `libc/libm`
version definitions.

| Plugin | DT_NEEDED | Highest GLIBC requirement | GLIBC COMPATIBLE? |
|---|---|---|---|
| performance_buffer.so  | libm.so.6, libc.so.6 | GLIBC_2.17 (`fmod@GLIBC_2.17`) | YES |
| performance_spectral.so| libm.so.6, libc.so.6, ld-linux-aarch64.so.1 | GLIBC_2.17 (`atan2f/cosf/sincosf@GLIBC_2.17`) | YES |
| performance_space.so   | libm.so.6, libc.so.6, ld-linux-aarch64.so.1 | GLIBC_2.27 (`expf/powf@GLIBC_2.27`; rest 2.17) | YES |
| performance_granular.so| libm.so.6, libc.so.6 | GLIBC_2.17 (`cosf/fmod@GLIBC_2.17`) | YES |

Machine-verified in `rebuilt/REBUILD_ABI_CHECK.txt`:
"ALL VERSION NEEDS SATISFIED BY 407 SYSROOT" (every `(library, version)`
need in every rebuilt .so present in that 407 library's version definitions;
`GLIBC_PRIVATE` only for `errno`, provided).

## 4. Per-dependency resolution (brief §24)

Each rebuilt DT_NEEDED was resolved against the 407 filesystem:

| dependency          | found in 407? | path (image) |
|---|---|---|
| libc.so.6           | yes | /usr/lib/aarch64-linux-gnu/libc.so.6 |
| libm.so.6           | yes | /lib/aarch64-linux-gnu/libm.so.6 |
| ld-linux-aarch64.so.1 | yes | /usr/lib/ld-linux-aarch64.so.1 |

No other DT_NEEDED entries exist in any of the four rebuilt plugins.
Notes:
- The `ld-linux-aarch64.so.1` NEEDED in spectral/space is normal Debian
  aarch64 behaviour: the 407's own `libc.so` linker script pulls
  `libc_nonshared.a`, which references `__stack_chk_guard` (provided by the
  dynamic linker on AArch64). Image-native binaries carry the same entry.
- libgcc_s / libstdc++: **not required** — the plugins are C `-fPIC -shared`;
  no C++ ABI, no libgcc runtime symbols appear in the undefined tables.

## 5. Claim labels (strict terminology)

- Old v2.0.1 `.so` files: **GLIBC-INCOMPATIBLE with the 407 image** — do not deploy.
- Rebuilt `.so` files: **GLIBC COMPATIBLE** and **407-SYSROOT COMPILED**.
  Per brief §23 they must NOT yet be called "fully Beebo compatible":
  LV2 ABI/ingen-level and audible behaviour on the device remain
  TARGET-BLOCKED until a real unit runs them.

## 6. Integration plan pointer

Deployment is out of scope for this pass (brief §28 — nothing copied into
the image). The integration plan belongs to the next phase; the rebuilt
bundles would be shipped as `.lv2` bundles with `manifest.ttl`, placed
per the 407 plugin scan path (`/usr/lib/lv2`, 234 bundles scanned by
Lilv 0.24.25 via Ingen 0.5.1) — see `INGEN_LV2_STACK.md`. **PROPOSED only.**