wzssyqa wrote:
>
> Sure. The motivation on our side is a distributed compile service where the
> library doesn't exist on the remote end. This patch means we'll have to add
> knowledge about path layouts at link time to the remote setup at compile
> time. That's certainly doable, but kind of
mstorsjo wrote:
> > I would suggest we revert this - and at least collect all the observed side
> > effects and declare them before considering relanding it.
>
> That sounds good to me. Do you have a list of PRs to revert?
Not sure if there are follow-up fixes, sorry, but the discussed PRs
nico wrote:
> I would suggest we revert this - and at least collect all the observed side
> effects and declare them before considering relanding it.
That sounds good to me. Do you have a list of PRs to revert?
> ... then we do still get the old name embedded.
Sure. The motivation on our
mstorsjo wrote:
> I now did build clang at
> [ccdebba](https://github.com/llvm/llvm-project/commit/ccdebbae4d77d3efc236af92c22941de5d437e01)
> and
> [ccdebba](https://github.com/llvm/llvm-project/commit/ccdebbae4d77d3efc236af92c22941de5d437e01)^.
>
>
wzssyqa wrote:
Will the contents of `empty.asm` correct if `lib//clang_rt.profile.lib`
doesn't exist?
I mean, will `empty.asm` contains `/DEFAULTLIB:clang_rt.profile-x86_64.lib`
then?
https://github.com/llvm/llvm-project/pull/87866
___
cfe-commits
nico wrote:
I now did build clang at ccdebbae4d77 and ccdebbae4d77^. ccdebbae4d77 has
`/DEFAULTLIB:clang_rt.profile.lib` in its output, ccdebbae4d77^ has
/DEFAULTLIB:clang_rt.profile-x86_64.lib`. So definitely due to this change.
It sounds like you're saying that's not intentional?
(It's
nico wrote:
Here's a minimal repro:
```
% cat empty.c
% foo/clang --driver-mode=cl empty.c --target=x86_64-pc-windows
-fprofile-instr-generate -c /Fa && rg DEFAULTLIB empty.asm
23: .ascii " /DEFAULTLIB:libcmt.lib"
24: .ascii " /DEFAULTLIB:oldnames.lib"
25: .ascii "
mstorsjo wrote:
> This is a behavior change: In distributed build environments, neither lib
> file exists at compile time. Previously, this would result in the "old"
> style, now (together with #81037) it results in the "new" style (which we
> disable everywhere since it causes all kinds of
nico wrote:
This is a behavior change: In distributed build environments, neither lib file
exists at compile time. Previously, this would result in the "old" style, now
(together with #81037) it results in the "new" style (which we disable
everywhere since it causes all kinds of issues – from
jhuber6 wrote:
It's definitely not ideal that this prints a non-existent path if the
per-target runtime directory configuration is off. Couldn't we just do a
trivial filesystem check to make sure it exists before appending it?
https://github.com/llvm/llvm-project/pull/87866
estewart08 wrote:
> > Is it expected now that `clang --print-runtime-dir` will always have the
> > clang host triple appended even if `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is
> > off? I guess I was expecting to see `lib/linux` instead of
> > `lib/x86_64-unknown-linux-gnu`.
>
>
mstorsjo wrote:
> > Is it expected now that `clang --print-runtime-dir` will always have the
> > clang host triple appended even if `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is
> > off? I guess I was expecting to see `lib/linux` instead of
> > `lib/x86_64-unknown-linux-gnu`.
>
>
MaskRay wrote:
> Is it expected now that `clang --print-runtime-dir` will always have the
> clang host triple appended even if `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is
> off? I guess I was expecting to see `lib/linux` instead of
> `lib/x86_64-unknown-linux-gnu`.
estewart08 wrote:
Is it expected now that `clang --print-runtime-dir` will always have the clang
host triple appended even if `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is off?
https://github.com/llvm/llvm-project/pull/87866
___
cfe-commits mailing list
wzssyqa wrote:
See: https://github.com/llvm/llvm-project/pull/87866
Can you have a try to add an extra option
```
-resource-dir=%S/Inputs/resource_dir
```
https://github.com/llvm/llvm-project/pull/87866
___
cfe-commits mailing list
antmox wrote:
Hello @MaskRay @bazuzi,
Looks like one of the commit ([Driver] Ensure ToolChain::LibraryPaths is not
empty for non-Darwin) broke the clang-arm64-windows-msvc-2stage bot here:
https://lab.llvm.org/buildbot/#/builders/120/builds/6489
Old compiler-rt lib seems still used
wzssyqa wrote:
New PR with my resource-dir patch:
https://github.com/llvm/llvm-project/pull/88661
https://github.com/llvm/llvm-project/pull/87866
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
aeubanks wrote:
yeah that patch makes those test pass with this PR, lgtm
(you could also test locally by touching the files I mentioned above, e.g. even
just `touch lib/clang/19/lib/linux/libclang_rt.builtins-aarch64-android.a`
repro'd the test failure on my machine)
wzssyqa wrote:
[xx.patch](https://github.com/llvm/llvm-project/files/14948921/xx.patch)
@aeubanks can you help to test this patch?
https://github.com/llvm/llvm-project/pull/87866
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
wzssyqa wrote:
> > @aeubanks The problem is that in your configure, the libclang_rt is placed
> > in `/lib/clang/19/lib/linux/libclang_rt.builtins-arm-android.a`,
> > instead of
> > `/lib/clang/19/lib/arm-unknown-linux-android/libclang_rt.builtins.a`.
>
> The point is that both locations
mstorsjo wrote:
> @aeubanks The problem is that in your configure, the libclang_rt is placed in
> `/lib/clang/19/lib/linux/libclang_rt.builtins-arm-android.a`,
> instead of
> `/lib/clang/19/lib/arm-unknown-linux-android/libclang_rt.builtins.a`.
The point is that both locations were supposed
wzssyqa wrote:
@aeubanks The problem is that in your configure, the libclang_rt is please in
`/lib/clang/19/lib/linux/libclang_rt.builtins-arm-android.a`, instead
of
`/lib/clang/19/lib/arm-unknown-linux-android/libclang_rt.builtins.a`.
https://github.com/llvm/llvm-project/pull/87866
aeubanks wrote:
it seems that the test depends on if certain android runtime libraries are
present or not in the resource dir (without per-target runtime directory since
that's still an issue on Android). perhaps the tests need `-resource-dir` to
make them more hermetic?
anyway, will revert,
aeubanks wrote:
this seemes to be causing some test failures for us:
https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket/8751043232043110529/+/u/package_clang/stdout?format=raw
```
TEST 'Clang :: Driver/linux-ld.c' FAILED
RUN: at line
wzssyqa wrote:
For me, I think that it is a good idea to always warn/hint the full/normalized
path.
For compatible reason, we can still try to find libraries in old-style or
non-full/normalized paths, while should not hint them.
https://github.com/llvm/llvm-project/pull/87866
mstorsjo wrote:
> This seems to have had an unexpected effect. In a build where I don't use the
> new path style, I used to get the old path style returned like this:
>
> ```
> $ clang -target x86_64-w64-mingw32 -print-runtime-dir
> /home/martin/clang-nightly/lib/clang/19/lib/windows
> ```
>
mstorsjo wrote:
This seems to have had an unexpected effect. In a build where I don't use the
new path style, I used to get the old path style returned like this:
```
$ clang -target x86_64-w64-mingw32 -print-runtime-dir
/home/martin/clang-nightly/lib/clang/19/lib/windows
```
However after this
https://github.com/MaskRay closed
https://github.com/llvm/llvm-project/pull/87866
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/87866
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MaskRay updated
https://github.com/llvm/llvm-project/pull/87866
>From 2847b8be2e4938c03aea57609842e2fee776d916 Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Fri, 5 Apr 2024 21:51:37 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
30 matches
Mail list logo
