Ok, a long story short, this issue should only occurred when RTE_QAT_LIBIPSECMB is enabled. It was intend to remove Openssl lib dependency in QAT replaced with ipsec_mb lib, but the work was partially done due to limitation of ipsec_mb by the time (FIPS certification)
I'm happy with current fix and please cc: sta...@dpdk.org The fully removal of Openssl dependency is already ongoing, I will take a note to fix this properly Regards Kai > -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Wednesday, January 11, 2023 11:21 PM > To: Ji, Kai <kai...@intel.com>; De Lara Guarch, Pablo > <pablo.de.lara.gua...@intel.com>; Akhil Goyal <gak...@marvell.com> > Cc: dev@dpdk.org; Tyler Retzlaff <roret...@linux.microsoft.com>; > dev@dpdk.org; David Marchand <david.march...@redhat.com>; Dooley, Brian > <brian.doo...@intel.com>; Power, Ciara <ciara.po...@intel.com>; Mcnamara, > John <john.mcnam...@intel.com> > Subject: Re: [PATCH] crypto/qat: fix build > > Waiting for an answer here. > The commit log is not supposed to stay like this with questions. > > > 11/01/2023 10:03, Thomas Monjalon: > > 04/01/2023 12:56, Akhil Goyal: > > > > On Fri, Dec 30, 2022 at 10:07:28PM +0100, Thomas Monjalon wrote: > > > > > When trying to compile on a fresh system, I hit this error: > > > > > > > > > > intel-ipsec-mb.h:333: error: "AES_BLOCK_SIZE" redefined > > > > > 333 | #define AES_BLOCK_SIZE IMB_AES_BLOCK_SIZE > > > > > In file included from drivers/crypto/qat/qat_sym_session.c:8: > > > > > /usr/include/openssl/aes.h:26: previous definition > > > > > 26 | # define AES_BLOCK_SIZE 16 > > > > > > > > > > I don't know why it was not seen before. > > > > > Is it because of a change in intel-ipsec-mb.h or in OpenSSL? > > > > > > > > > > Signed-off-by: Thomas Monjalon <tho...@monjalon.net> > > > > > --- > > > > > > > > owners of intel-ipsec-mb.h should guard against the namespace > > > > conflict... > > > > > > > > Acked-by: Tyler Retzlaff <roret...@linux.microsoft.com> > > > > > > Applied to dpdk-next-crypto > > If there is no better fix, we should at least add Cc: sta...@dpdk.org > assuming it could be reproduced with an older DPDK. > > > > > > > Thanks. > > > > I'm concerned to have no answer from Pablo and Kai. > > It is real design problem. Is there any plan to have a protected > namespace? > >
