[anutosh491]

Template A: Checklist for adding a package

Pre-submission Checks

• Package requires building for emscripten-wasm32 platform (not a noarch package), in other words, the package requires compilation.

Recipe Structure

Added recipes/recipes_emscripten/[package-name]/recipe.yaml with proper structure:

• context section with version (and optionally name)
• package section with name and version using Jinja2 templates
• source section with:
  • Source URL is valid and points to archive file (.tar.gz, .tar.bz2, .tar.xz, .tgz, or .zip)
  • Source URL contains ${{ version }} template for version updates
  • SHA256 hash is correct (verified with curl -sL <url> | sha256sum)
  • Patches (if any) are included in [package-name]/patches/ directory
• build section with appropriate script/method
  • Python packages: ${PYTHON} -m pip install . ${PIP_ARGS}
  • R packages: $R CMD INSTALL $R_ARGS .
  • C++ packages: Uses emcmake/emmake or emconfigure/emmake
  • Rust packages: Uses rust-nightly and maturin or appropriate Rust build tool
  • Build number is 0
  • If the script is longer than 3 lines, a build.sh is included
• requirements section (build, host, run as needed)
• tests section
  • Python packages: test_import_[package].py file created and referenced
  • C++ packages: Test executable or package_contents test
  • R packages: Package contents test
• about section with license, homepage, summary

---

Template B: Checklist for updating a package

• ⚠️ Bump build number if the version remains unchanged
• Or reset build number to 0 if updating the package to a newer version

---

PR Formatting

• PR title follows format: Add [package-name] or Update [package-name] to [version]
• PR description includes:
  • Version being added/updated
  • Any special build considerations or patches applied

Package Details

• Package Name:
• Version:

Build Notes

[anutosh491]

I realize I should probably write a line or two explaining the changes other than the pytorch recipe (missed it cause was working on this pr through the weekend). Writing something soon !

[anutosh491]

Making note of some not-so-obvious changes !

All mostly come from PyTorch tests on both wasm32 and wasm64:

• pytester: torch.compile imports torch.utils.cpp_extension, which needs setuptools at runtime. We already declare that dependency, but the filter removed setuptools and _distutils_hack from the browser archive, so Inductor failed with ModuleNotFoundError.

• pthread detection: generic-testing was matching any occurrence of “pthread”, including the data symbol FLAGS_pthreadpool_size. It now matches pthread_* symbol names, so actual pthread symbols still fail the check.

• Memoryless wrappers: libtorch.so, _C.so and libtorch_global_deps.so are tiny dependency/entry-point wrappers, the implementation lives in libtorch_cpu.so and libtorch_python.so. Those wrappers can contain only functions and declare no memory width, which makes LLVM default to reporting wasm32. The exception is restricted to function-only shared wrappers, modules with defined or imported memory still get the architecture check.

• NumPy run exports: NumPy is needed in the shared staging build for the Python bindings. Its run export is ignored there so it doesn’t make the C++ libtorch output depend on NumPy/Python. The pytorch output declares host NumPy separately and still gets its ABI constraint—confirmed as numpy >=2.2,<3 in CI.

Let me think through other changes that need a mention.