On 2015/3/5 22:39, Thomas Monjalon wrote:
> 2015-03-05 14:03, Qiu, Michael:
>> On 3/5/2015 9:54 PM, David Marchand wrote:
>>> On Thu, Mar 5, 2015 at 2:50 PM, Michael Qiu <michael.qiu at intel.com
>>> <mailto:michael.qiu at intel.com>> wrote:
>>>
>>> include/rte_cpuflags.h:154:2: error: redeclaration of enumerator
>>> ?REG_EAX?
>>> In file included from /usr/include/signal.h:358:0,
>>> from /usr/include/sys/wait.h:30,
>>> from /root/dpdk/app/test/test_mp_secondary.c:50:
>>> /usr/include/sys/ucontext.h:180:3: note: previous definition of
>>> ?REG_EAX? was here
>>>
>>> In i686, from REG_EAX to REG_EDX are all defined in
>>> /usr/include/sys/ucontext.h
>>>
>>> Rename to CPU_REG_EAX to avoid this issue.
>>>
>>> Signed-off-by: Michael Qou <michael.qiu at intel.com
>>> <mailto:michael.qiu at intel.com>>
>>>
>>>
>>> NAK.
>>>
>> I have answered in you last thread, please check the mail.
>>
>> Yes, but for some reason, it was not include, see /usr/include/signal.h:358
>>
>> # include <bits/sigstack.h>
>> # if defined __USE_XOPEN || defined __USE_XOPEN2K8
>> /* This will define `ucontext_t' and `mcontext_t'. */
>> # include <sys/ucontext.h>
>> # endif
>>
>> So only if __USE_XOPEN or __USE_XOPEN2K8 been defined will include
>> <sys/ucontext.h>
> So try to define USE_XOPEN.
>
>> Why NAK?
> Because it seems you didn't really try to include system headers.
See below(ucontext.h:25):
#ifdef __x86_64__
...
#ifdef __USE_GNU
enmu{
...
REG_RBX,
# define REG_RBX REG_RBX
REG_RDX,
# define REG_RDX REG_RDX
REG_RAX,
# define REG_RAX REG_RAX
REG_RCX,
# define REG_RCX REG_RCX
...
};
#endif
...
#else /* !__x86_64__ */
...
#ifdef __USE_GNU
enmu{
...
REG_EBX,
# define REG_EBX REG_EBX
REG_EDX,
# define REG_EDX REG_EDX
REG_ECX,
# define REG_ECX REG_ECX
REG_EAX,
# define REG_EAX REG_EAX
...
};
#endif
...
#endif /* !__x86_64__ */
For none x86_64 platform will be defined as REG_E*X, but x86_64 will be
REG_R*X.
This is why only happens in i686 platform.
Does this clear?
Thanks,
Michael
> We must avoid redefine existing symbols. That's why this bug happens.
> Michael, thanks for trying to fix this issue. It's appreciated even if
> the first solution is refused.
>
>
