examples/sotest: support packaged shared library fixtures

[aviralgarg05]

Summary

This patch is another smaller upstream slice being extracted from the ongoing GSoC 2026 Dynamic ELF loading and nxpkg work for NuttX.

An earlier draft PR (#3474) carries the initial nxpkg package lifecycle helper. PR #3519 carries a separate apps/ module-support cleanup slice from the same broader effort. This PR is independent of #3519, but can still be reviewed after it to keep the follow-up series orderly.

Series order for this PR:

• base series context: system/nxpkg: add a basic package lifecycle helper #3474
• technical dependency: after system/nxpkg: add a basic package lifecycle helper #3474
• review preference: after apps: add missing module metadata for executable tools #3519

The change itself extends the examples/sotest packaging path so the shared-library test fixtures can also be prepared through nxpkg-style package artifacts.

Concretely, it:

• generates shared-index.json and pkgsotest.nsh from the built modprint and sotest shared objects
• records the correct target arch / compat metadata and SHA-256 digests for those packaged shared-library fixtures
• allows sotest to run in either its existing builtin-ROMFS flow or from explicit shared-library paths, with a --mount helper mode for preparing the builtin test mount separately
• keeps the paired fixture outputs in one grouped make step so parallel builds do not re-enter the generator independently

Impact

This makes the sotest shared-library example usable as a package-style fixture producer for the same Dynamic ELF / nxpkg series.

That is useful for validating the shared-library side of the packaging flow, where the loader should consume installed artifacts rather than only the default builtin test paths.

There is no intended regression for the normal sotest example flow. The existing builtin-ROMFS path is preserved, while the test binary now also accepts explicit shared-library paths when the package-installed copies need to be exercised.

Keeping this work separate from the larger series should make review easier, while still preserving the intended merge order after #3474.

Testing

Host:

• macOS 26.5
• Apple Silicon (arm64)
• xtensa-esp-elf-gcc (crosstool-NG esp-14.2.0_20241119) 14.2.0
• esptool.py v4.11.0

Focused verification for this PR:

• clean detached apps worktree with this patch stacked on top of the current #3474 head
• clean detached companion apache/nuttx worktree at the local boards/xtensa/esp32s3/xiao:sotest: enable nxpkg fixtures commit used for the matching XIAO configuration
• target: xtensa
• config: esp32s3-xiao:sotest

Build steps:

./tools/configure.sh -E -a ../apps-stacked esp32s3-xiao:sotest
make olddefconfig
make -j8

Generated fixture artifacts:

bin/shared-index.json
bin/pkgsotest.nsh

Build result:

LD: nuttx
CP: nuttx.hex
MKIMAGE: ESP32-S3 binary
Generated: nuttx.bin

Broader series context:

• this slice was verified specifically for clean build and fixture generation in the stacked setup above
• the broader Dynamic ELF / nxpkg series has been validated separately on the Seeed XIAO ESP32S3 Sense during the ongoing bring-up work, but this PR description is intentionally limiting its direct claim to the focused stacked verification above

[acassis]

@aviralgarg05 and this one here?

[acassis]

@aviralgarg05 what about CMakeLists.txt doesn't it need to be modified as well?

[aviralgarg05]

Sorry, I missed the matching CMakeLists.txt update. I’ll fix that and then get it ready for the review

[aviralgarg05]

I checked the failing run, and this one does not seem to be caused by the patch itself. The failure is happening while the CI job tries to pull the shared container image from ghcr.io, before the actual build/test steps start. Since multiple matrix jobs are failing at that stage, this looks more like an infrastructure/network issue than a code issue in this PR.

@acassis Can you pls help me understand if there is something wrong with my code

[acassis]

I checked the failing run, and this one does not seem to be caused by the patch itself. The failure is happening while the CI job tries to pull the shared container image from ghcr.io, before the actual build/test steps start. Since multiple matrix jobs are failing at that stage, this looks more like an infrastructure/network issue than a code issue in this PR.

@acassis Can you pls help me understand if there is something wrong with my code

Don't worry, it is a github failure, I just restart the Job

[linguini1]

After reading the description and reviewing your code, I'm still uncertain what this PR is doing? Is this to make sotest a loadable application through nxpkg?

This PR includes Python scripts as part of the build process, which I remember was a contentious issue. Is it okay to enforce that the user has Python for this?

[aviralgarg05]

I pushed an update for this.

The Python generators added by this PR are removed now. The shared fixture helper is now a small C host tool, and the CMake path no longer introduces Python into the build flow.

Also, the goal here is not to make sotest an end-user nxpkg app. The intent is to generate package-style shared-library fixtures so the shared-library loading path can be validated using installed artifacts instead of only the default builtin test layout.

[linguini1]

Can you explain what a "package-style fixture producer" is? I'm not sure I really understand, sorry.

Also, please squash your commits.

[aviralgarg05]

@linguini1

By “package-style fixture producer”, I mean the small host-side helper that generates the test package metadata and script files for the packaged sotest flow.

In this case it takes the built shared-library artifacts and writes the fixture files used by nxpkg, so the packaged install/run path is exercised as part of the example instead of only the plain builtin layout.

[linguini1]

@linguini1

By “package-style fixture producer”, I mean the small host-side helper that generates the test package metadata and script files for the packaged sotest flow.

In this case it takes the built shared-library artifacts and writes the fixture files used by nxpkg, so the packaged install/run path is exercised as part of the example instead of only the plain builtin layout.

What is the packaged sotest flow? Like installing sotest from a package?

[aviralgarg05]

Yes, exactly.

[linguini1]

It doesn't really seem sustainable to have host side tools for every application in order to generate these files. It should probably be a central build tool that works for making any package compatible with nxpkg

[aviralgarg05]

For this PR, I was trying to keep the scope limited to replacing the Python dependency in the existing example-local fixture path.

I agree the better long-term direction is a shared build helper for nxpkg-compatible fixture generation, instead of per-example host tools. I can keep this PR scoped as-is and we can follow up with that cleanup separately.

[linguini1]

For this PR, I was trying to keep the scope limited to replacing the Python dependency in the existing example-local fixture path.

But that doesn't make sense, because this PR is what added the Python dependency? So there was nothing to remove, just a change in your implementation of the patch.

I agree the better long-term direction is a shared build helper for nxpkg-compatible fixture generation, instead of per-example host tools. I can keep this PR scoped as-is and we can follow up with that cleanup separately.

I think it would be better to start your feature correctly to make it easier for you to package more applications later, but if it's easier then it's okay to put this one in using C-based host tools.

Also another thing for later would be to included a SHA hash library instead of rolling your own. But I think it's fine for this PR!