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