rui314/setup-mold

A GitHub Action to install the mold linker

This action downloads and installs the mold linker as the default linker.

Usage

Just add the following line to the steps: list in your GitHub Action YAML file:

- uses: rui314/setup-mold@v1

You can optionally pass parameters to the action as follows:

- uses: rui314/setup-mold@v1
  with:
    mold-version: 1.1.1
    make-default: false

mold-version specifies the mold version to install. By default, the most recent version will be installed.

If make-default: false is specified, mold will still be installed as /usr/local/bin/mold but it won't replace the default linker. If you choose not to install mold as the default linker, you need to pass an appropriate option such as -fuse-ld=mold to the compiler to use mold.

setup-mold's Issues

Action modifies permission of /usr/local/bin

Running this action modifies the permissions of /usr/local/bin from the default of the github runners

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
    - uses: actions/checkout@v4
    - name: Reveal permissions
      run: ls -l /usr/local
    - uses: rui314/setup-mold@v1
    - name: Reveal permissions
      run: ls -l /usr/local

Before

drwxrwxrwx  2 root root  4096 Dec 17 22:23 bin

After

drwxr-xr-x  2 root root  4096 Nov 29 08:58 bin

This breaks other actions that assume the default setup and tries to place binaries in /usr/local/bin

note requirement on `wget` package

It's worth noting that this action requires wget to be installed. I'm working with a container that doesn't already have it installed, so I had to install it. Not a big deal, but maybe work mentioning.

Action fails when sudo is missing

This action fails in an environment without sudo.

Common use-case is a blank docker container such as ubuntu:22.04, which runs as root by default and has no sudo installed.

Rust

Tried this on the CI setup of my Github repository but it doesn't seem to improve the compilation speed.

Does this action create a config.toml pointing to this linker by default? If not it would be useful if it did for Rust repositories!

Fix symlink creation

Hi @rui314,

Thank you for all the wonderful projects! 🥇 👍
And, thank you for this GitHub action!

I was trying to integrate this in a GitHub CI pipeline and observed this:

• mold is extracted to /usr/local/bin/mold
• but the symlink is created from /usr/bin/mold i.e.

  setup-mold/action.yml

  Line 17 in 1c4945c

  - run: test ${{ inputs.make-default }} = true && sudo ln -sf /usr/bin/mold $(realpath /usr/bin/ld); true

I had to add a separate step to fix the symlink creation from the correct path:

sudo ln -sf /usr/local/bin/mold $(realpath /usr/bin/ld)

Verified:

$ realpath /usr/bin/ld
/usr/local/bin/mold

$ ld --version
mold 1.1.1 (c1af9c97e763a1d521889191a83b27bd6c43b351; compatible with GNU ld)

I'll submit a PR shortly.
Thanks!

Update for 2.4.1 release

New 2.4.1 release is out but the default version of setup-mold is still 2.4.0

https://github.com/rui314/mold/releases/tag/v2.4.1

curl doesn't retry if interrupted mid-download

I got this failure, in ~1 out of ~10k runs, which I presume is due to a failure midway through the download.

2024-02-09T15:58:37.7421248Z ##[group]Run echo "mold 2.4.0"
2024-02-09T15:58:37.7421692Z echo "mold 2.4.0"
2024-02-09T15:58:37.7423005Z curl -L --retry 10 --silent --show-error https://github.com/rui314/mold/releases/download/v2.4.0/mold-2.4.0-$(uname -m)-linux.tar.gz | sudo tar -C /usr/local --strip-components=1 --no-overwrite-dir -xzf -
2024-02-09T15:58:37.7424876Z test true = true -a "$(realpath /usr/bin/ld)" != /usr/local/bin/mold && sudo ln -sf /usr/local/bin/mold "$(realpath /usr/bin/ld)"; true
2024-02-09T15:58:37.7482329Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
2024-02-09T15:58:37.7482854Z env:
2024-02-09T15:58:37.7483131Z   CARGO_TERM_COLOR: always
2024-02-09T15:58:37.7483502Z   CARGO_INCREMENTAL: 0
2024-02-09T15:58:37.7489553Z   CARGO_NET_RETRY: 10
2024-02-09T15:58:37.7489893Z   RUSTUP_MAX_RETRIES: 10
2024-02-09T15:58:37.7493595Z   DEBIAN_FRONTEND: noninteractive
2024-02-09T15:58:37.7495040Z   BASE_REF: main
2024-02-09T15:58:37.7495863Z ##[endgroup]
2024-02-09T15:58:37.7571733Z mold 2.4.0
2024-02-09T15:58:49.4437863Z 
2024-02-09T15:58:49.4441032Z gzip: stdin: not in gzip format
2024-02-09T15:58:49.4444883Z tar: Child died with signal 13
2024-02-09T15:58:49.4445395Z tar: Error is not recoverable: exiting now
2024-02-09T15:58:49.4453902Z curl: (23) Failure writing output to destination
2024-02-09T15:58:49.4488957Z ##[error]Process completed with exit code 2.

You switched from wget to curl in b2554cc to resolve #6.

I just wanted to raise the possibility of switching back to wget with these arguments which should solve both issues:

wget -q --secure-protocol=TLSv1_2 --https-only --retry-connrefused --waitretry=1 --read-timeout=20 --timeout=15 -t10 --no-dns-cache --retry-on-http-error=429,500,502,503,504,509 -O- https://...
# --https-only and --retry-on-http-error need to be removed for old versions of wget

wget is theoretically robust to resuming on these kinds of mid-download failures.

An alternative is downloading to an intermediate file rather than piping directly to tar, which may also solve this.

Tag all releases

The README.md suggests:

- uses: rui314/setup-mold@v1

However the latest and only "v1" tag has not been updated for the recent commits, e.g. https://github.com/rui314/setup-mold/compare/v1..main

It would be best if each "release" gets its own tag. e.g. "v1.0.2" and a major version tag such as "v1" gets updated continously, see https://docs.github.com/en/actions/creating-actions/about-custom-actions#using-release-management-for-actions
This would also help for pinning full-length sha with a version comment for https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

If you'd rather not do tags, I suggest you update your doc to:

- uses: rui314/setup-mold@main

See https://docs.github.com/en/actions/creating-actions/about-custom-actions#using-branches-for-release-management
This way users of the action constantly get (possibly breaking) updates.

Creating symbolic link can fail on self-hosted runner

When make-default is enabled and the action runs on the self-hosted runner, this action can fail with following error:

ln: ‘/usr/local/bin/mold’ and ‘/usr/local/bin/mold’ are the same file

This is because the self-hosted runner environment can be reused so that the symbolic link created by the previous run exists.
To resolve this, I think there are some options:

1. Check if there is an existing link before ln
2. Add cleanup steps to remove this symbolic link
3. Change nothing, and recommend to setup mold in their self-hosted runner by themselves

I'd like to hear your opinion. Thank you!

wget returns exit code 8

We end up seeing this occasionally.

My guess is that wget from github occasionally fails. Most likely one or two retries inside the setup-mold step would go a long way here. Other suggestions welcome too.