Build statically linked Linux binaries in CI #5872
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR provides statically linked Linux binaries to resolve all those glibc compatibility issues once and for all. 😃
This is achieved by
-cclib -static -cclib -no-pie
to the dune files for the executables built with OCaml.LDFLAGS=-static
to the build for the ninja executable.(See https://ocamlpro.com/blog/2021_09_02_generating_static_and_portable_executables_with_ocaml for more information.)
The Docker image used is in the GitHub Container Registry as
ghcr.io/rescript-lang/rescript-ci-build
. Sources are at https://github.com/rescript-lang/docker-rescript-ci-build.Docker support in Github actions has many limitations. While it is possible to run a single build step in Docker, it is then run as root in the Docker container, resulting in permission issues with the generated files. The only approach I finally got to work was to build the compiler and ninja binaries in a separate job and upload them as artifacts, to be used by the for the Linux platform in the existing build job (in place of building them from source there).
This additional job for building the static binaries needs to complete before the normal build job (for all platforms) can be started. It is fairly quick though (~2 minutes) as all dependencies are already preinstalled in the Docker container used. Still, this unfortunately increases the total execution time for the CI workflow.
I also had to make a cleaner separation in the Makefile and scripts between the dune build and the subsequent stdlib build/tests. These should not use
dune exec
to avoid triggering a rebuild of the executables with different settings. (Alsodune exec
at least checks for changes and so comes with some performance cost anyway.)The generated binaries were tested successfully on NixOS, see #5694 (comment).