Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Attempt to fix CI #582

Merged
merged 1 commit into from
Mar 28, 2024
Merged

Attempt to fix CI #582

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/workflows/main.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ jobs:
name: Test
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
include:
- target: aarch64-unknown-linux-gnu
Expand Down
2 changes: 1 addition & 1 deletion ci/docker/thumbv6m-none-eabi/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,4 +4,4 @@ RUN apt-get update && \
gcc libc6-dev ca-certificates \
gcc-arm-none-eabi \
libnewlib-arm-none-eabi
ENV XARGO=1
ENV NO_STD=1
2 changes: 1 addition & 1 deletion ci/docker/thumbv7em-none-eabi/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,4 +4,4 @@ RUN apt-get update && \
gcc libc6-dev ca-certificates \
gcc-arm-none-eabi \
libnewlib-arm-none-eabi
ENV XARGO=1
ENV NO_STD=1
2 changes: 1 addition & 1 deletion ci/docker/thumbv7em-none-eabihf/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,4 +4,4 @@ RUN apt-get update && \
gcc libc6-dev ca-certificates \
gcc-arm-none-eabi \
libnewlib-arm-none-eabi
ENV XARGO=1
ENV NO_STD=1
2 changes: 1 addition & 1 deletion ci/docker/thumbv7m-none-eabi/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,4 +4,4 @@ RUN apt-get update && \
gcc libc6-dev ca-certificates \
gcc-arm-none-eabi \
libnewlib-arm-none-eabi
ENV XARGO=1
ENV NO_STD=1
58 changes: 32 additions & 26 deletions ci/run.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,7 @@
set -ex

cargo=cargo

# Test our implementation
if [ "$XARGO" = "1" ]; then
# FIXME: currently these tests don't work...
if [ "$NO_STD" = "1" ]; then
echo nothing to do
else
run="cargo test --manifest-path testcrate/Cargo.toml --target $1"
Expand All @@ -16,6 +13,15 @@ else
$run --features no-asm --release
fi

if [ -d /target ]; then
path=/target/${1}/debug/deps/libcompiler_builtins-*.rlib
else
path=target/${1}/debug/deps/libcompiler_builtins-*.rlib
fi

# Remove any existing artifacts from previous tests that don't set #![compiler_builtins]
rm -f $path

cargo build --target $1
cargo build --target $1 --release
cargo build --target $1 --features c
Expand All @@ -36,15 +42,15 @@ case $1 in
;;
esac

NM=$(find $(rustc --print sysroot) -name llvm-nm)
NM=$(find $(rustc --print sysroot) \( -name llvm-nm -o -name llvm-nm.exe \) )
Copy link
Contributor

@dpaoliello dpaoliello Mar 27, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this is causing the issue: comparing a working job to the failing one using llvm-nm instead of nm on i686-pc-windows-gnu is causing the tests to fail.

When I try to run llvm-nm locally in MinGW32, I get error while loading shared libraries: ?: cannot open shared object file: No such file or directory and an exit code of 127. Perhaps we're missing also missing some shared libraries required to run this on the CI machines?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be libLLVM.dll itself. Try prefixing the command with rustup run +nightly. That will set the dynamic linker path as necessary.

Copy link
Member

@RalfJung RalfJung Mar 27, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test passes on windows, it's only macOS where it fails. See the CI results.

Never mind. I didn't realize the macOS thing was resolved.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be libLLVM.dll itself. Try prefixing the command with rustup run +nightly. That will set the dynamic linker path as necessary.

Good call - that fixed the issue. I don't think it was libLLVM.dll (since that's not in the toolchain), but rather libgcc_s_dw2-1.dll and libwinpthread-1.dll.

I had to do a bit extra since not every build has rustup on the path, and the toolchain isn't always called nightly, but I now have this working: 4242372 @Amanieu feel free to steal that commit, or I can publish the draft PR if you prefer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking into this! I implemented a similar workaround based on yours but without the need for a second argument to run.sh.

if [ "$NM" = "" ]; then
NM=${PREFIX}nm
fi

if [ -d /target ]; then
path=/target/${1}/debug/deps/libcompiler_builtins-*.rlib
else
path=target/${1}/debug/deps/libcompiler_builtins-*.rlib
# i686-pc-windows-gnu tools have a dependency on some DLLs, so run it with
# rustup run to ensure that those are in PATH.
TOOLCHAIN=$(rustup show active-toolchain | sed 's/ (default)//')
if [[ $TOOLCHAIN == *i686-pc-windows-gnu ]]; then
NM="rustup run $TOOLCHAIN $NM"
fi

# Look out for duplicated symbols when we include the compiler-rt (C) implementation
Expand Down Expand Up @@ -79,29 +85,29 @@ done
rm -f $path

# Verify that we haven't drop any intrinsic/symbol
build_intrinsics="$cargo build --target $1 -v --example intrinsics"
RUSTFLAGS="-C debug-assertions=no" $build_intrinsics
RUSTFLAGS="-C debug-assertions=no" $build_intrinsics --release
RUSTFLAGS="-C debug-assertions=no" $build_intrinsics --features c
RUSTFLAGS="-C debug-assertions=no" $build_intrinsics --features c --release
build_intrinsics="cargo build --target $1 -v --example intrinsics"
$build_intrinsics
$build_intrinsics --release
$build_intrinsics --features c
$build_intrinsics --features c --release

# Verify that there are no undefined symbols to `panic` within our
# implementations
#
# TODO(#79) fix the undefined references problem for debug-assertions+lto
if [ -z "$DEBUG_LTO_BUILD_DOESNT_WORK" ]; then
RUSTFLAGS="-C debug-assertions=no" \
CARGO_INCREMENTAL=0 \
CARGO_PROFILE_DEV_LTO=true \
$cargo rustc --features "$INTRINSICS_FEATURES" --target $1 --example intrinsics
fi
CARGO_PROFILE_DEV_LTO=true \
cargo build --target $1 --example intrinsics
CARGO_PROFILE_RELEASE_LTO=true \
$cargo rustc --features "$INTRINSICS_FEATURES" --target $1 --example intrinsics --release
cargo build --target $1 --example intrinsics --release

# Ensure no references to a panicking function
# Ensure no references to any symbols from core
for rlib in $(echo $path); do
set +ex
$NM -u $rlib 2>&1 | grep panicking
echo "================================================================"
echo checking $rlib for references to core
echo "================================================================"

$NM --quiet -U $rlib | grep 'T _ZN4core' | awk '{print $3}' | sort | uniq > defined_symbols.txt
$NM --quiet -u $rlib | grep 'U _ZN4core' | awk '{print $2}' | sort | uniq > undefined_symbols.txt
grep -v -F -x -f defined_symbols.txt undefined_symbols.txt

if test $? = 0; then
exit 1
Expand Down