Hi All,
On 1/14/26 18:05, Alban MOIZAN wrote:
Hi,
No wrappers around the compilers. In my experience, wrapping an executable
to manipulate the parameters just causes to many issues with observability
and debug issues. So that rules out option #3 IMHO.
Understandable, I remove this one.
Honestly, I just lean towards #5 while the handling is worked out upstream
between the tools. I don't use ccache, and don't have the impression that
it is in widespread use .. but with the right amount of data, I could
be convinced
I'm wrong on that.
I mean, it is not only a ccache issue, it is for possible future (or
existing like `sccache`) other tools, the issue make any
`CC="<my-wrapper-tool> <my-compiler>"` incompatible with a kernel
built with rust for now.
This issue is definitely not specific to ccache, but rather intrinsic to
how rustc
handles the -Clinker argument. It rejects any HOSTCC that is a composite
string,
regardless of whether it is a wrapper or just flags.
I recently encountered this exact scenario in another build environment
completely unrelated to ccache. In that case, HOSTCC was defined as a
composite string
embedding flags to ensure host settings were respected (e.g.,
HOSTCC="gcc <cflags> <ldflags>").
As a result, rustc took the executable path correctly but interpreted
the rest of the string
as arguments intended for itself, which naturally caused the build to fail.
Regarding this specific ccache failure: when I first worked on this series,
I did not encounter the problem as I do not use ccache by default. It
was actually reported by Yoann,
who had it enabled in his configuration. We considered disabling ccache
but as Alban points out
this is not a ccache-specific issue. It affects any setup involving a
composite HOSTCC.
That being said, I'd also add: Don't worry about enabling ALL kernels while
working through the enablement. By that, I mean if there's a simple
kernel patch,
I could carry it on linux-yocto while upstream work is happening, and we could
confirm no ccache issues there. The patch could also be taken by other kernel
maintainers that want it for their configuration, but we wouldn't have
to do much
else on that front.
Then I will try do give you a patch soon.
I haven't gone and looked at any code, but isn't it just simpler to
filter ccache
out in the kernel Makefile's themselves before any rust invocations ? I assume
that is inherent in your option 1/2, but the comment about needing to patch
rustc as well has me wondering.
Filter out on the kernel is my proposed solution 4
4. Kernel only: Patch the kernel Makefile to filter out `ccache` from CC (works
in practice but not generic for a possible other wrapper in the future).
While technically working, it is still not compatible with
`CC="<my-wrapper-tool> <my-compiler>"` things more generically.
In fact, as I said on my Trial 1, since rustc `-Clinker` only accepts
Paths (or things in $PATH), you can only mitigate the ccache issue,
but not the overall issue, without patching rustc.
I can try to send a patch to rust with my proposed solution 1 and see
what append on their side.
Thanks for your help.
Bruce
Thank you for responding,
Alban
Best regards,
Mehdi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#229392):
https://lists.openembedded.org/g/openembedded-core/message/229392
Mute This Topic: https://lists.openembedded.org/mt/116997869/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
