On Thursday 27 December 2012, Arnd Bergmann wrote:
> On Wednesday 19 December 2012, Riku Voipio wrote:
> > Hi,
> >
> > The following code fails to build with OE Aarch64 toolchain with
> > current kernel headers. While ugly, the code is a reduced testcase
> > from fuse build failure (
> > https://bugs.launchpad.net/linaro-oe/+bug/1087757 ) and the same fuse
> > code compiles on all other architectures. Before I send a workaround
> > for upstream, I'd like to know how we can end up with different
> > definitions for int64_t when that happens on no other architectures -
> > something wrong with the generic kernel headers?
>
> I think the problem here is that user space redefines the __s64 type,
> which is already defined by the kernel and is in the reserved namespace.
>
> In the kernel, most architectures nowadays use "long long" for s64,
> while in user space, 64 bit platforms traditionally use "long" for
> int64_t, hence the conflict that happens here but not on some other
> architectures. Normally these don't conflict, since the "long long"
> variant is only used for kernel interfaces.
>
> I don't know why the fuse header does this, because it's otherwise
> a straight copy of include/linux/fuse.h, except that it redefines
> the basic integer types.
It was this commit that introduced the problem in fuse back in 2008,
in combination with the kernel moving to int-ll64.t for 64-bit
architectures that are presumably all broken now:
fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=blob;f=include/fuse_kernel.h;hb=5f722fa8f6561c964fd0bd651b4602ac0f7bc3b4
On x86, this never showed up, because its bits/sigcontext.h
does not include asm/sigcontext.h, which it does on arm64,
causing the conflicting __s64 definition to be pulled in
through linux/types.h.
I think it would be good to change the fuse private header
file copy to undefine all the __u64 and related types
at the end, which will make new fuse version work with
the existing glibc and kernel header files on all architectures.
We might also want to look into the situation in arm64 glibc:
if this is the only architecture that uses asm/sigcontext.h
directly, we could change glibc to have a copy of that rather
than including the kernel version, just in case some other
user space tool has the same dependency, and to make existing
fuse versions build. It's a bit of a hack though.
Arnd
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
