examples/sotest: Support packaged shared-library fixtures.

[aviralgarg05]

Summary

Extend examples/sotest so its built shared objects can be used as generated
nxpkg test fixtures.

A small C host helper generates shared-index.json and pkgsotest.nsh from
the built modprint and sotest artifacts. The generated metadata contains
the target architecture, compatibility value, and SHA-256 digests.

The existing builtin-ROMFS flow remains available. The test application can
also receive explicit shared-library paths, allowing the installed copies to
be exercised.

The generated script seeds both the original /etc/nxpkg/index.json catalog
location and #3642's default /var/lib/nxpkg/index.jsn location. This keeps
the standalone fixture usable before and after the storage migration.

Impact

• New feature: YES, limited to generated shared-library test fixtures.
• User adaptation: NO.
• Build: YES for examples/sotest; a C host helper is used by Make and CMake.
• Hardware: NO architecture, board, or driver change.
• Documentation: NO user documentation is required for this test fixture.
• Security: NO runtime trust change.
• Compatibility: The existing builtin-ROMFS path remains available.
• Other: This does not turn sotest into a general end-user package or
  change nxpkg runtime behavior.

Testing

Host:

• macOS 26.5, arm64
• xtensa-esp-elf-gcc 14.2.0
  (esp-14.2.0_20241119)

Target:

• esp32s3-xiao:sotest

Verification:

• clean Make build and 285,468-byte nuttx.bin link;
• current-upstream CMake sotest_artifacts build, including both loadable
  ELFs, host helper, symbol table, catalog, script, and ROMFS;
• generated bin/shared-index.json;
• generated bin/pkgsotest.nsh; and
• exact SHA-256 agreement between both generated ELF inputs and the catalog.

Testing logs before change:

N/A: the packaged shared-library fixture and generated script do not exist on
the PR base.

Testing logs after change:

Make outputs:
  modprint           1680 bytes
  sotest             3648 bytes
  shared-index.json   865 bytes
  pkgsotest.nsh       398 bytes
  nuttx.bin        285468 bytes

CMake outputs against current upstream NuttX:
  modprint           1268 bytes
  sotest             2312 bytes
  shared-index.json   867 bytes
  pkgsotest.nsh       398 bytes

  Every package entry's SHA-256 exactly matches its CMake-built ELF.

  The related older NuttX branch needs already-upstream fix ace40bfbfc before
  it can configure loadable applications with CMake; this is not introduced
  by the apps patch.

Real hardware (ESP32-S3):
  nxpkg installed modprint 1.0.0 and sotest 1.0.0.
  The installed paths were passed explicitly to sotest.
  All three shared-library test functions completed.
  nxpkg list reported the expected shared-lib type and target metadata.

The full retained serial transcript should be attached with the signed update.

PR verification Self-Check

• This PR introduces one focused validation-fixture change.
• I have updated all required description fields above.
• I have reviewed and signed the rewritten commit.
• I have collected before/after real-hardware runtime logs.
• This PR adheres to the current contribution and coding guidelines.
• My PR is still work in progress.
• My PR is ready for review and can be safely merged.

[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!

[aviralgarg05]

That’s fair
I’ll keep this version as-is for now so the current feature can move forward, and I’ll keep the shared helper direction in mind for follow-up cleanup later. Also noted on the SHA part.

[linguini1]

You should squash your commit of removing the Python scripts since then it will just be that you added a C script to begin with.

[aviralgarg05]

Updated as one signed commit. The fixture generator is a C host tool used by both Make and CMake, and the generated script seeds both the original catalog location and nxpkg’s persistent-root location. On the ESP32-S3 target, modprint and sotest installed successfully and all three shared-library test functions completed. Fresh CI is queued on the new head.