6 Commits

Author SHA1 Message Date
Fangrui Song
b876596a76
[Driver] Improve error when a compiler-rt library is not found (#81037)
BSD, Linux, and z/OS enable `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` by
default.
When a compiler-rt library is not found, we currently report an
incorrect filename `libclang_rt.XXX-$arch.a`
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=address -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```

With this change, we will correctly report:
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=address -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```

Link: https://discourse.llvm.org/t/runtime-directory-fallback/76860
2024-02-26 09:55:02 -08:00
Fangrui Song
4ca0480a4f
[Driver,BareMetal] Replace -lclang_rt.builtins{,-$arch}.a with an absolute path (#82424)
The generic `tools::AddRunTimeLibs` uses an absolute path. Change
BareMetal to match.

I believe users are not supposed to place other files under the
directory containing `libclang_rt.builtins-$arch.a`. If they rely on the
implicit -L, they now need to explicitly specify -L.
2024-02-20 16:54:27 -08:00
Tim Northover
4f637c30e1 [tests][Driver] Pass an empty sysroot for DEFAULT_SYSROOT builds
The baremetal-sysroot test fails when the toolchain is configured with
DEFAULT_SYSROOT. So, to emulate not having passed one at all, let's
pass an empty sysroot instead.

https://reviews.llvm.org/D119144

Patch by Carlo Cabrera <carlo.antonio.cabrera@gmail.com>
2022-03-04 09:01:50 +00:00
Petr Hosek
f97ada27aa Revert "[BareMetal] Ensure that sysroot always comes after library paths"
This reverts commit 6b00b34b8a05896f79b18a1963811299b83d5b21.
2021-05-07 13:38:04 -07:00
Petr Hosek
6b00b34b8a [BareMetal] Ensure that sysroot always comes after library paths
This addresses an issue introduced in D91559. We would invoke the
compiler with -Lpath/to/lib --sysroot=path/to/sysroot where both
locations contain libraries with the same name, but we expect linker
to pick up the library in path/to/lib since that version is more
specialized. This was the case before D91559 where the sysroot path
would be ignored, but after that change linker would now pick up the
library from the sysroot which resulted in unexpected behavior.

The sysroot path should always come after any user provided library
paths, followed by compiler runtime paths. We want for libraries in user
provided library paths to always take precedence over sysroot libraries.
This matches the behavior of other toolchains used with other targets.

Differential Revision: https://reviews.llvm.org/D102049
2021-05-07 13:21:07 -07:00
Hafiz Abid Qadeer
275592e714 Provide default location of sysroot for Baremetal toolchain.
Currently, Baremetal toolchain requires user to pass a sysroot location
using a --sysroot flag. This is not very convenient for the user. It also
creates problem for toolchain vendors who don't have a fixed location to
put the sysroot bits.

Clang does provide 'DEFAULT_SYSROOT' which can be used by the toolchain
builder to provide the default location. But it does not work if toolchain
is targeting multiple targets e.g. arm-none-eabi/riscv64-unknown-elf which
clang is capable of doing.

This patch tries to solve this problem by providing a default location of
the toolchain if user does not explicitly provides --sysroot. The exact
location and name can be different but it should fulfill these conditions:

1. The sysroot path should have a target triple element so that multi-target
toolchain problem (as I described above) could be addressed.

2. The location should not be $TOP/$Triple as this is used by gcc generally
and will be a problem for installing both gcc and clang based toolchain at
the same location.

Reviewed By: jroelofs

Differential Revision: https://reviews.llvm.org/D92677
2020-12-07 09:19:52 +00:00