Hi Jerin, I have created a patch to MUSDK that fix this conflicts as you suggested. This will be externally available in the next MUSDK release. Once it will be out, we can simplify the armada-config, but until then if anyone want to build DPDK with MUSDK it either needs this patch or compile MUSDK as shared lib
Regards, Liron -----Original Message----- From: Liron Himi Sent: Monday, 2 December 2019 08:32 To: Jerin Jacob <jerinjac...@gmail.com> Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dpdk-dev <dev@dpdk.org>; dpdk stable <sta...@dpdk.org>; Liron Himi <lir...@marvell.com> Subject: RE: [EXT] Re: [dpdk-dev] [PATCH] config: update Marvell ARMADA Regards, Liron -----Original Message----- From: Jerin Jacob <jerinjac...@gmail.com> Sent: Monday, 2 December 2019 06:12 To: Liron Himi <lir...@marvell.com> Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dpdk-dev <dev@dpdk.org>; dpdk stable <sta...@dpdk.org> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH] config: update Marvell ARMADA > > ---------------------------------------------------------------------- > On Fri, Nov 29, 2019 at 3:55 PM <lir...@marvell.com> wrote: > > > > From: Liron Himi <lir...@marvell.com> > > > > disable more NXP modules that conflict with MUSDK > > # Please share more details on the conflict. > [L.H.] both components calls of_<x> APIs so when MUSDK is compiled statically > it conflicts with NXP's code. If something implemented in the library, IMO, it should start with the library name to avoid namespace collision. Are we implementing of_x calls in MUSDK? [L.H.] yes. It is not the same implementation as in dpaa_of.c Could you share the error logs? [L.H.] /home/userlab/work/combined_git/dataplane/musdk/usr/local/lib/libmusdk.a(libmusdk_la-of.o): In function `of_n_addr_cells': /home/userlab/work/combined_git/dataplane/musdk/src/env/of.c:348: multiple definition of `of_n_addr_cells' /home/userlab/work/combined_git/dataplane/dpdk-19.11/build/lib/librte_common_dpaax.a(dpaa_of.o):dpaa_of.c:(.text+0x13b8): first defined here > Note that the original armada config already had some NXP flags disabled, but > in recent version NXP moved the of_<x> code to be depends on > 'CONFIG_RTE_LIBRTE_COMMON_DPAAX' so needed to update it. OK > # What about meson build? "make" will be deprecated soon. > [L.H.] only when compiling the MUSDK as static LIBs, we face this issue. In > meson we need to compile MUSDK as shared LIBS. But nothing stopping us to compile MUSDK as static build with meson. Right? [L.H.] right, but currently it will not work AFAIK there is no way to exclude modules from meson builds per configuration file (as we have with 'make' flow), right? > # This scheme won't work for distro build, Please spend the effort to analyze > the conflict and fix the conflict. IMO, That would be the correct solution. > > > > > > Signed-off-by: Liron Himi <lir...@marvell.com> > > --- > > config/defconfig_arm64-armada-linuxapp-gcc | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/config/defconfig_arm64-armada-linuxapp-gcc > > b/config/defconfig_arm64-armada-linuxapp-gcc > > index 059180284..c09751cf0 100644 > > --- a/config/defconfig_arm64-armada-linuxapp-gcc > > +++ b/config/defconfig_arm64-armada-linuxapp-gcc > > @@ -19,6 +19,23 @@ CONFIG_RTE_LIBRTE_PMD_MVSAM_CRYPTO=y > > > > # Disable NXP as it is conflict with MUSDK > > CONFIG_RTE_LIBRTE_DPAA_BUS=n > > +CONFIG_RTE_LIBRTE_COMMON_DPAAX=n > > +CONFIG_RTE_LIBRTE_FSLMC_BUS=n > > +CONFIG_RTE_LIBRTE_DPAA2_MEMPOOL=n > > +CONFIG_RTE_LIBRTE_DPAA2_PMD=n > > +CONFIG_RTE_LIBRTE_DPAA_BUS=n > > +CONFIG_RTE_LIBRTE_DPAA_MEMPOOL=n > > +CONFIG_RTE_LIBRTE_DPAA_PMD=n > > +CONFIG_RTE_LIBRTE_PMD_DPAA_EVENTDEV=n > > +CONFIG_RTE_LIBRTE_PMD_DPAA_SEC=n > > +CONFIG_RTE_LIBRTE_PMD_CAAM_JR=n > > +CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV=n > > +CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC=n > > +CONFIG_RTE_LIBRTE_PMD_DPAA2_CMDIF_RAWDEV=n > > +CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV=n > > +CONFIG_RTE_LIBRTE_PFE_PMD=n > > +CONFIG_RTE_LIBRTE_ENETC_PMD=n > > + > > > > # Doesn't support NUMA > > CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n > > -- > > 2.23.0 > >
