builtins/clear_cache.c depends on kernel headers.
It's difficult to ascertain whether it's mixing with libc headers
but if it is then that's a bug in its own right.
Either way, it's pulling in kernel headers for a single #defined
constant that's been part of the linux ABI for years now. This
makes it more difficult to cross compile for, in my opinion, no
good reason. So here's a patch to just place the #define inline.
I'm not a member of the list so please CC me on replies.
diff --git a/lib/builtins/clear_cache.c b/lib/builtins/clear_cache.c
index 4c2ac3b..191598d 100644
--- a/lib/builtins/clear_cache.c
+++ b/lib/builtins/clear_cache.c
@@ -82,10 +82,6 @@ uintptr_t GetCurrentProcess(void);
#endif
#endif
-#if defined(__linux__) && defined(__arm__)
- #include <asm/unistd.h>
-#endif
compiler-rt-remove-kernel-header.patch (842 Bytes)
Hi Joakim,
Sorry it took so long. I'm copying Saleem who knows more than I do about this.
That define seems harmless. I checked kernel 3.13 and current trunk
and the defines are the same. For compatibility, I seriously doubt
they're going to change it anytime soon.
I'd just add a comment where that line is from
(arch/arm/include/uapi/asm/unistd.h).
Saleem, any objections?
cheers,
--renato
Hmm, I dont think that this is terrible. However, since I dont belive that Linux guarantees the stability of its interfaces, I think that adding a trivial test for this would be waranteed.
I think Linux is pretty far towards the conservative end on changing
syscalls (via the "don't break user space" rule that Linus is keen
on). Windows & macOS, you're on your own.
Tim.
Ok, I committed in r295738. Let's see if this causes any trouble, but
I'm not expecting any.
Thanks Joakim!
cheers,
--renato