Jean Philippe EIMER wrote:
> > Compiling coreutils 8.3 fails at ls.c, with gcc 4.4.2, glibc 2.11.1 and
> > kernel 2.6.32.3 :
> >
> > In file included from /usr/include/bits/sigcontext.h:28,
> > from /usr/include/signal.h:339,
> > from ../lib/signal.h:34,
> > from ls.c:67:
> > /usr/include/asm/sigcontext.h:28: error: expected specifier-qualifier-list
> > before '__u64'
> > /usr/include/asm/sigcontext.h:267: error: expected specifier-qualifier-list
> > before '__u64'
You did not tell the architecture, but from the line numbers I infer that it
is x86 (not x86_64). Right?
The error message indicates that __u64 is not known as a type at the point
where <asm/sigcontext.h> needs it. This is bizarre, because
1) Nothing in coreutils 8.3, gnulib, nor glibc 2.11.1 fiddles with __u64.
2) The linux-2.6.32.3 headers make sure __u64 is defined:
/usr/include/bits/sigcontext.h includes /usr/include/asm/sigcontext.h.
/usr/include/asm/sigcontext.h includes /usr/include/linux/types.h.
/usr/include/linux/types.h includes /usr/include/asm/types.h.
/usr/include/asm/types.h includes /usr/include/asm-generic/types.h.
/usr/include/asm-generic/types.h includes
/usr/include/asm-generic/int-ll64.h.
/usr/include/asm-generic/int-ll64.h defines __u64 like this:
#ifdef __GNUC__
__extension__ typedef __signed__ long long __s64;
__extension__ typedef unsigned long long __u64;
#else
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
> > Moving up #include <signal.h> just after #include <sys/types.h> in
> > src/ls.c solves this compilation issue.
This is a workaround that most likely does not address the root of the problem.
Can you show the relevant parts of "gcc -E" (preprocessed input) and "gcc -E
-dM"
(macro definitions) of the compilation command of ls.c?
Bruno
