History log of /wasmtime-44.0.1/ci/docker/x86_64-linux/Dockerfile (Results 1 – 9 of 9)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2
# 43c5412a 25-Aug-2025 Alex Crichton <[email protected]>

Try to make CI more robust with more retries (#11532)

* Try to make CI more robust with more retries

Try adding `--retry` to a bunch of `curl` commands to see if we can make
CI a bit more robust in

Try to make CI more robust with more retries (#11532)

* Try to make CI more robust with more retries

Try adding `--retry` to a bunch of `curl` commands to see if we can make
CI a bit more robust in the face of flaky network failures.

prtest:full

* See if rustls is less flaky

* See if curl isn't flaky?

show more ...


Revision tags: v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0, v32.0.0, v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0, v27.0.0, v26.0.1, v25.0.3, v24.0.2
# b9436666 24-Oct-2024 Alex Crichton <[email protected]>

Update nightly in CI (#9501)

* Update nightly in CI

This commit updates nightly again in CI after failing to do so in #9496.
This fixes an issue in our release CI where CMake was misconfigured when

Update nightly in CI (#9501)

* Update nightly in CI

This commit updates nightly again in CI after failing to do so in #9496.
This fixes an issue in our release CI where CMake was misconfigured when
cross-compiling and creating `aarch64-pc-windows-msvc` artifacts.

prtest:full

* Try installing ninja

* Also install Ninja on Linux

show more ...


Revision tags: v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1, v25.0.1, v25.0.0
# 2389dcce 20-Aug-2024 Alex Crichton <[email protected]>

Try again to fix version info in CI builds (#9157)

Turns out just having `git` wasn't enough. In the containers things are
running as `root` and `git` doesn't like that so try to convince git
that i

Try again to fix version info in CI builds (#9157)

Turns out just having `git` wasn't enough. In the containers things are
running as `root` and `git` doesn't like that so try to convince git
that it should like it.

show more ...


# a8607bf8 20-Aug-2024 Alex Crichton <[email protected]>

Install `git` executable in container builds (#9152)

Precompiled artifacts for macOS show this for `wasmtime --version`

wasmtime-cli 24.0.0 (6fc3d274c 2024-08-20)

whereas for Linux they show

Install `git` executable in container builds (#9152)

Precompiled artifacts for macOS show this for `wasmtime --version`

wasmtime-cli 24.0.0 (6fc3d274c 2024-08-20)

whereas for Linux they show

wasmtime-cli 24.0.0

and this is due to `git` not being available in the build environment on
Linux.

show more ...


Revision tags: v24.0.0, v23.0.2
# dd3aac60 12-Aug-2024 Alex Crichton <[email protected]>

Clean up dist build configuration (#9113)

* Clean up dist build configuration

* Move updating `$PATH` to the `main.js` script which is the one that
mounts `/rust/bin` so that knowledge isn't spre

Clean up dist build configuration (#9113)

* Clean up dist build configuration

* Move updating `$PATH` to the `main.js` script which is the one that
mounts `/rust/bin` so that knowledge isn't spread around.
* Remove some unused env vars in docker containers.
* Forward cargo/rust-specific env vars to the build from outside of
containers to the build itself.

prtest:full

* Change how musl rustflags are configured

* More rustflags changes

* Review feedback

show more ...


Revision tags: v23.0.1, v23.0.0
# 58b4d093 02-Jul-2024 Trevor Elliott <[email protected]>

Use cmake 3.26, which is available in AlmaLinux 8 (#8896)

prtest:full


# 248bc65e 02-Jul-2024 Trevor Elliott <[email protected]>

Use AlmaLinux:8 for x86_64-linux binary-compatible-builds (#8892)

* Use Ubuntu-16.04 for x86_64-linux binary-compatible-builds

* Revert "Use Ubuntu-16.04 for x86_64-linux binary-compatible-builds"

Use AlmaLinux:8 for x86_64-linux binary-compatible-builds (#8892)

* Use Ubuntu-16.04 for x86_64-linux binary-compatible-builds

* Revert "Use Ubuntu-16.04 for x86_64-linux binary-compatible-builds"

This reverts commit 5625941dee84f27f1d47851908790fcd7d474b3a.

* Use AlmaLinux 8

prtest:full

show more ...


Revision tags: v22.0.0, v21.0.1, v21.0.0
# 566669ee 20-May-2024 Alex Crichton <[email protected]>

Refactor installation of C API and features supported (#8642)

* Refactor installation of C API and features supported

This commit overhauls and refactors the management of the building of
the C AP

Refactor installation of C API and features supported (#8642)

* Refactor installation of C API and features supported

This commit overhauls and refactors the management of the building of
the C API. Instead of this being script-based it's now done entirely
through CMake and CMake is the primary focus for building the C API. For
example building the C API release artifacts is now done through CMake
instead of through a shell script's `cargo build` and manually moving
artifacts.

The benefits that this brings are:

* The C API now properly hides symbols in its header files that weren't
enabled at build time. This is done through a new build-time generated
`conf.h` templated on a `conf.h.in` file in the source tree.

* The C API's project now supports enabling/disabling Cargo features to
have finer-grained support over what's included (plus auto-management
of the header file).

* Building the C API and managing it is now exclusively done through
CMake. For example invoking `doxygen` now lives in CMake, installation
lives there, etc.

The `CMakeLists.txt` file for the C API is overhauled in the process of
doing this. The build now primarily matches on the Rust target being
built rather than the host target. Additionally installation will now
install both the static and shared libraries instead of just one.
Additionally during this refactoring various bits and pieces of
Android-specific code were all removed. Management of the C toolchain
feels best left in scope of the caller (e.g. configuring `CC_*` env vars
and such) rather than here.

prtest:full

* Don't use `option` for optional strings

* Invert release build check

Also adjust some indentation

* Fix more indentation

* Remove no-longer-used variable

* Reduce duplication in feature macro

show more ...


Revision tags: v20.0.2, v20.0.1, v20.0.0, v17.0.3, v19.0.2, v18.0.4, v19.0.1, v19.0.0, v18.0.3, v18.0.2, v17.0.2, v18.0.1, v18.0.0, v17.0.1, v17.0.0, v16.0.0, v15.0.1, v15.0.0, v14.0.4, v14.0.3, v14.0.2, v13.0.1, v14.0.1, v14.0.0, minimum-viable-wasi-proxy-serve, v13.0.0, v12.0.2, v11.0.2, v10.0.2, v12.0.1, v12.0.0, v11.0.1, v11.0.0, v10.0.1, v10.0.0, v9.0.4, v9.0.3, v9.0.2, v9.0.1, v9.0.0, v6.0.2, v7.0.1, v8.0.1, v8.0.0, v7.0.0, v6.0.1, v5.0.1, v4.0.1, v6.0.0, v5.0.0, v4.0.0, v3.0.1, v3.0.0, v1.0.2, v2.0.2, v2.0.1, v2.0.0, v1.0.1, v1.0.0, v0.40.1, v0.40.0, v0.39.1, v0.38.3, v0.38.2, v0.39.0, v0.38.1, v0.38.0
# 08b7c877 20-May-2022 Alex Crichton <[email protected]>

Refactor binary-compatible-builds for releases (#4171)

* Refactor binary-compatible-builds for releases

I was poking around this yesterday and noticed a few things that could
be improved for our

Refactor binary-compatible-builds for releases (#4171)

* Refactor binary-compatible-builds for releases

I was poking around this yesterday and noticed a few things that could
be improved for our release builds:

* The centos container for the x86_64 builds contained a bunch of extra
tooling we no longer need such as python3 and a C++ compiler. Along
with custom toolchain things this could all get removed since the C we
include now is quite simple.

* The aarch64 and s390x cross-compiled builds had relatively high glibc
version requirements compared to the x86_64 build. This was because we
don't use a container to build the cross-compiled binaries. I added
containers here along the lines of the x86_64 build to use an older
glibc to build the release binary to lower our version requirement.
This lower the aarch64 version requirement from glibc 2.28 to 2.17.
Additionally the s390x requirement dropped from 2.28 to 2.16.

* To make the containers a bit easier to read/write I added
`Dockerfile`s for them in a new `ci/docker` directory instead of
hardcoding install commands in JS.

This isn't intended to be a really big change or anything for anyone,
but it's intended to keep our Linux-based builds consistent at least as
best we can.

* Remove temporary change

show more ...