From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id CFB465680 for ; Thu, 29 Sep 2016 21:30:36 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP; 29 Sep 2016 12:30:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,268,1473145200"; d="scan'208";a="885198493" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by orsmga003.jf.intel.com with ESMTP; 29 Sep 2016 12:30:34 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.164]) by IRSMSX154.ger.corp.intel.com ([169.254.12.149]) with mapi id 14.03.0248.002; Thu, 29 Sep 2016 20:30:32 +0100 From: "De Lara Guarch, Pablo" To: Adrien Mazarguil CC: "dev@dpdk.org" , "Doherty, Declan" Thread-Topic: [PATCH] cryptodev: fix compilation error in SUSE 11 SP2 Thread-Index: AQHSGD/aV4rHUlHYI0eJwr3tmbq/aKCM5O+AgAP3GnA= Date: Thu, 29 Sep 2016 19:30:31 +0000 Message-ID: References: <1474926635-13290-1-git-send-email-pablo.de.lara.guarch@intel.com> <20160927074521.GY17252@6wind.com> In-Reply-To: <20160927074521.GY17252@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjZiNzczN2ItYzA0Ny00ZjQxLWFmNGUtOWYxZjRmOWY1YTVkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlRneDBKejVtSjJlQXhlYmdKWE1OZGhWK1ZHOHYzbHJOTG92V09nVHp3bUk9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] cryptodev: fix compilation error in SUSE 11 SP2 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, 29 Sep 2016 19:30:37 -0000 > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Tuesday, September 27, 2016 12:45 AM > To: De Lara Guarch, Pablo > Cc: dev@dpdk.org; Doherty, Declan > Subject: Re: [PATCH] cryptodev: fix compilation error in SUSE 11 SP2 >=20 > On Mon, Sep 26, 2016 at 10:50:35PM +0100, Pablo de Lara wrote: > > This commit fixes following build error, which happens in SUSE 11 SP2, > > with gcc 4.5.1: > > > > In file included from lib/librte_cryptodev/rte_cryptodev.c:71:0: > > lib/librte_cryptodev/rte_cryptodev_pmd.h:76:7: > > error: flexible array member in otherwise empty struct > > > > Fixes: 347a1e037fd3 ("lib: use C99 syntax for zero-size arrays") > > > > Signed-off-by: Pablo de Lara >=20 > Hmm, this error message does not seem related to your patch. Assuming a > similar error is caused by the original code, I think there is a more > important issue as the struct should not be empty. Can you check the > error? Well, I don't really understand what is the difference between array[] and = array[0], I thought both were the same, but some compilers only accept the latter. In any case, the struct will not be empty, as there are other fields, that = are not variable sized. I saw that in your patch you made these two changes (among others): diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rt= e_cryptodev.h index affbdec..1e30a19 100644 --- a/lib/librte_cryptodev/rte_cryptodev.h +++ b/lib/librte_cryptodev/rte_cryptodev.h @@ -759,7 +759,7 @@ struct rte_cryptodev_sym_session { } __rte_aligned(8); /**< Public symmetric session details */ - char _private[0]; + char _private[]; /**< Private session material */ }; diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h b/lib/librte_cryptode= v/rte_cryptodev_pmd.h index 7d049ea..42e7b79 100644 --- a/lib/librte_cryptodev/rte_cryptodev_pmd.h +++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h @@ -71,7 +71,7 @@ struct rte_cryptodev_session { struct rte_mempool *mp; } __rte_aligned(8); - char _private[0]; + __extension__ char _private[0]; }; So I would expect the same change in both, as they are almost identical, but you took different approaches (do you know why? I would like to know :)= ) Basically, I noticed that gcc 4.5 doesn't complain when using your second a= pproach, that's why I changed it. Thanks, Pablo