From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 058F65A73 for ; Thu, 5 Mar 2015 17:31:30 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP; 05 Mar 2015 08:28:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,348,1422950400"; d="scan'208";a="687427613" Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103]) by fmsmga002.fm.intel.com with ESMTP; 05 Mar 2015 08:31:28 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 6 Mar 2015 00:31:27 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.192]) by shsmsx102.ccr.corp.intel.com ([169.254.2.62]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 00:31:26 +0800 From: "Qiu, Michael" To: Thomas Monjalon Thread-Topic: =?Windows-1252?Q?[dpdk-dev]_[PATCH_3/3_v2]_librte=5Feal/common:_Fix_redec?= =?Windows-1252?Q?laration_of_enumerator_=91REG=5FEAX=92?= Thread-Index: AQHQV0vgkuRRiHveXUOL5io868XXcQ== Date: Thu, 5 Mar 2015 16:31:25 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E60286CEF29E@SHSMSX101.ccr.corp.intel.com> References: <1425561339-13300-4-git-send-email-michael.qiu@intel.com> <533710CFB86FA344BFBF2D6802E60286CEEF6B@SHSMSX101.ccr.corp.intel.com> <2382780.BfG7EQavsa@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] =?windows-1252?q?=5BPATCH_3/3_v2=5D_librte=5Feal/commo?= =?windows-1252?q?n=3A_Fix_redeclaration_of_enumerator_=91REG=5FEAX=92?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:31:31 -0000 On 2015/3/5 22:39, Thomas Monjalon wrote:=0A= > 2015-03-05 14:03, Qiu, Michael:=0A= >> On 3/5/2015 9:54 PM, David Marchand wrote:=0A= >>> On Thu, Mar 5, 2015 at 2:50 PM, Michael Qiu >> > wrote:=0A= >>>=0A= >>> include/rte_cpuflags.h:154:2: error: redeclaration of enumerator=0A= >>> =91REG_EAX=92=0A= >>> In file included from /usr/include/signal.h:358:0,=0A= >>> from /usr/include/sys/wait.h:30,=0A= >>> from /root/dpdk/app/test/test_mp_secondary.c:50:= =0A= >>> /usr/include/sys/ucontext.h:180:3: note: previous definition of=0A= >>> =91REG_EAX=92 was here=0A= >>>=0A= >>> In i686, from REG_EAX to REG_EDX are all defined in=0A= >>> /usr/include/sys/ucontext.h=0A= >>>=0A= >>> Rename to CPU_REG_EAX to avoid this issue.=0A= >>>=0A= >>> Signed-off-by: Michael Qou >> >=0A= >>>=0A= >>>=0A= >>> NAK.=0A= >>>=0A= >> I have answered in you last thread, please check the mail.=0A= >>=0A= >> Yes, but for some reason, it was not include, see /usr/include/signal.h:= 358=0A= >>=0A= >> # include =0A= >> # if defined __USE_XOPEN || defined __USE_XOPEN2K8=0A= >> /* This will define `ucontext_t' and `mcontext_t'. */=0A= >> # include =0A= >> # endif=0A= >>=0A= >> So only if __USE_XOPEN or __USE_XOPEN2K8 been defined will include =0A= >> =0A= > So try to define USE_XOPEN.=0A= >=0A= >> Why NAK?=0A= > Because it seems you didn't really try to include system headers.=0A= =0A= See below(ucontext.h:25):=0A= #ifdef __x86_64__=0A= ...=0A= #ifdef __USE_GNU=0A= enmu{=0A= ...=0A= REG_RBX,=0A= # define REG_RBX REG_RBX=0A= REG_RDX,=0A= # define REG_RDX REG_RDX=0A= REG_RAX,=0A= # define REG_RAX REG_RAX=0A= REG_RCX,=0A= # define REG_RCX REG_RCX=0A= ...=0A= };=0A= #endif=0A= ...=0A= #else /* !__x86_64__ */=0A= ...=0A= #ifdef __USE_GNU=0A= enmu{=0A= ...=0A= REG_EBX,=0A= # define REG_EBX REG_EBX=0A= REG_EDX,=0A= # define REG_EDX REG_EDX=0A= REG_ECX,=0A= # define REG_ECX REG_ECX=0A= REG_EAX,=0A= # define REG_EAX REG_EAX=0A= ...=0A= };=0A= #endif=0A= ...=0A= #endif /* !__x86_64__ */=0A= =0A= =0A= For none x86_64 platform will be defined as REG_E*X, but x86_64 will be=0A= REG_R*X.=0A= =0A= This is why only happens in i686 platform.=0A= =0A= Does this clear?=0A= =0A= Thanks,=0A= Michael=0A= > We must avoid redefine existing symbols. That's why this bug happens.=0A= > Michael, thanks for trying to fix this issue. It's appreciated even if=0A= > the first solution is refused.=0A= >=0A= >=0A= =0A=