[libunwind] Fix libunwind library path for runtime test

[zeroomega]

This patch fixes an issue when test runner cannot find libwind library when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is used.

[zeroomega]

Test run on our downstream bot: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci.shadow/clang-linux-x64/b8735236964550803665/overview

This patch should address the build failure introduced in PR #110171

[llvmbot]

@llvm/pr-subscribers-libunwind

Author: Haowei (zeroomega)

Changes

This patch fixes an issue when test runner cannot find libwind library when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is used.

---

Full diff: https://github.com/llvm/llvm-project/pull/110777.diff

1 Files Affected:

• (modified) libunwind/test/configs/cmake-bridge.cfg.in (+1-1)

diff --git a/libunwind/test/configs/cmake-bridge.cfg.in b/libunwind/test/configs/cmake-bridge.cfg.in
index bd7122bbea32c4..f627f401f9f7b5 100644
--- a/libunwind/test/configs/cmake-bridge.cfg.in
+++ b/libunwind/test/configs/cmake-bridge.cfg.in
@@ -31,4 +31,4 @@ if not @LIBUNWIND_ENABLE_THREADS@:
 # Add substitutions for bootstrapping the test suite configuration
 config.substitutions.append(('%{install-prefix}', '@LIBUNWIND_TESTING_INSTALL_PREFIX@'))
 config.substitutions.append(('%{include}', '@LIBUNWIND_TESTING_INSTALL_PREFIX@/include'))
-config.substitutions.append(('%{lib}', '@LIBUNWIND_TESTING_INSTALL_PREFIX@/lib'))
+config.substitutions.append(('%{lib}', '@LIBUNWIND_TESTING_INSTALL_PREFIX@/@LIBUNWIND_INSTALL_LIBRARY_DIR@'))

[zeroomega]

Looks like #108999 broke the check bots.

[ldionne]

LGTM assuming the CI is green.

[ldionne]

I rebased onto main to trigger the CI again.

[ldionne]

This can be merged by whoever sees the CI green first.

[zeroomega]

This can be merged by whoever sees the CI green first.

There are 6 failing build so far but all due to the "runner received a shutdown signal", not actually a build/test failure? Should I do another rebase to trigger a rerun? Or we can just land it now?

[ldionne]

This can be merged by whoever sees the CI green first.

There are 6 failing build so far but all due to the "runner received a shutdown signal", not actually a build/test failure? Should I do another rebase to trigger a rerun? Or we can just land it now?

Merged since we have basically all green now. FYI, the "shutdown signal" thing is that our CI workers are running on preemptable VMs. So they sometimes get killed (shutdown signal) and we have another GH Action that restarts them. It's a bit funky but it saves a lot of cost for the fleet.