Hi there,
On Fri, 2021-06-11 at 10:59 +0100, Bruce Richardson wrote:
> On Fri, Jun 11, 2021 at 11:54:25AM +0200, David Marchand wrote:
> > Hello Bruce,
> >
> > On Wed, Jun 9, 2021 at 12:18 PM Michael Pfeiffer
> > <michael.pfeif...@tu-ilmenau.de> wrote:
> > >
> > > Including various headers may fail for ARM builds with 'Platform must
> > > be built with RTE_FORCE_INTRINSICS' if rte_config.h is not included
> > > before. Move the error message after the includes to ensure rte_config.h
> > > is always included.
> > >
> > > Fixes: de966ccdcd7f ("eal/arm: add byte order operations for ARM")
> > > Fixes: 17d5fa0fa90d ("eal/arm: add atomic operations for ARMv7")
> > > Fixes: d708f01b7102 ("eal/arm: add atomic operations for ARMv8")
> > > Fixes: 2173f3333b61 ("mcslock: add MCS queued lock implementation")
> > > Fixes: 7860c3965483 ("eal/arm: add spinlock operations for ARM")
> > > Fixes: ca49b92079df ("ticketlock: enable generic ticketlock on all arch")
> > > Cc: sta...@dpdk.org
> > > Cc: ko...@rehivetech.com
> > > Cc: phil.y...@arm.com
> > > Cc: joyce.k...@arm.com
> > >
> > > Signed-off-by: Michael Pfeiffer <michael.pfeif...@tu-ilmenau.de>
> >
> > The header check currently compiles all headers with an implicit
> > "-include rte_config.h".
> > I suppose this is because it comes from the project level meson
> > configuration.
> >
> > Would there be a way to detect the issue fixed by this patch?
> >
> I'm not convinced that there is an issue here. For DPDK compiles
> rte_config.h must always be included first, which is why it's included in
> the cflags reported by pkg-config. If we do want to move away from having
> rte_config as an omnipresent first include, we need to update many DPDK
> headers to explicitly include it.
the issue came up in our (rather large) DPDK app. Our build process uses a
hand-crafted build system (based on ninja) for native and cross builds, i.e.
pkg-config is not involved. It basically throws "-isystem <our-target-
prefix>/include/dpdk" into the compiler and omits linking some of the DPDK libs
not used by us.
This worked fine for us, and has no issues for x86 targets. I guess because
most headers do include rte_config (or rte_common) at least transitively before
doing anything else. Anyway, if you regard "-include rte_config.h" as the way
to go, this is fine for me. Its a one-liner for us and we can probably drop the
patch then.
Regards
Michael
