The VMR build.sh --help output describes the syntax of --with-system-libs, but there is no detailed documentation explaining its behavior or the packaging implications for produced runtime packs.
In particular, it is unclear that:
--with-system-libs all enables every system-library substitution recognized by the VMR build. It does not restrict substitutions to libraries included with the target operating system; required libraries may instead be supplied by the distribution or build environment.
- Enabling a system-library substitution may cause native artifacts in runtime packs to be built using a library supplied by the build environment instead of .NET's bundled implementation. If the resulting artifact links to that library dynamically, a compatible library must be available in the deployment environment.
- A subsequent
dotnet publish --self-contained copies the selected native assets from the runtime pack but does not generally discover and bundle arbitrary libraries to which those assets dynamically link. Those dependencies therefore remain external to the published output and must be supplied by the deployment environment.
This ambiguity contributed to #5632, where a Homebrew-built macOS runtime pack retained absolute dependencies on Homebrew's Brotli libraries.
Related: dotnet/runtime#4625
The VMR
build.sh --helpoutput describes the syntax of--with-system-libs, but there is no detailed documentation explaining its behavior or the packaging implications for produced runtime packs.In particular, it is unclear that:
--with-system-libs allenables every system-library substitution recognized by the VMR build. It does not restrict substitutions to libraries included with the target operating system; required libraries may instead be supplied by the distribution or build environment.dotnet publish --self-containedcopies the selected native assets from the runtime pack but does not generally discover and bundle arbitrary libraries to which those assets dynamically link. Those dependencies therefore remain external to the published output and must be supplied by the deployment environment.This ambiguity contributed to #5632, where a Homebrew-built macOS runtime pack retained absolute dependencies on Homebrew's Brotli libraries.
Related: dotnet/runtime#4625