bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ls.c doesn't compile


From: Jean Philippe EIMER
Subject: Re: ls.c doesn't compile
Date: Fri, 08 Jan 2010 21:59:32 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

Right, architecture is x86.

Attached is output of gcc -E -dM ls.c, and below extracted parts of gcc
-E ls.c :

# 6 "/usr/include/asm/sigcontext.h" 2 3 4
# 23 "/usr/include/asm/sigcontext.h" 3 4
struct _fpx_sw_bytes {
 __u32 magic1;
 __u32 extended_size;


 __u64 xstate_bv;




 __u32 xstate_size;




 __u32 padding[7];
};

----

# 266 "/usr/include/asm/sigcontext.h" 3 4
struct _xsave_hdr {
 __u64 xstate_bv;
 __u64 reserved1[2];
 __u64 reserved2[5];
};





Le 08/01/2010 21:12, Bruno Haible a écrit :
> 
> 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
> 
> 
> 

Attachment: gcc_E_dM
Description: X bitmap


reply via email to

[Prev in Thread] Current Thread [Next in Thread]