DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: pbhagavatula@marvell.com, jerinj@marvell.com, dev@dpdk.org,
	stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] buildtools: fix pmdinfogen compilation
Date: Wed, 31 Jul 2019 15:30:37 +0100	[thread overview]
Message-ID: <20190731143037.GE1705@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20190731142145.GC1705@bricha3-MOBL.ger.corp.intel.com>

On Wed, Jul 31, 2019 at 03:21:46PM +0100, Bruce Richardson wrote:
> On Wed, Jul 31, 2019 at 07:35:03AM -0400, Neil Horman wrote:
> > On Wed, Jul 31, 2019 at 11:57:05AM +0530, pbhagavatula@marvell.com wrote:
> > > From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > > 
> > > Pmdinfogen is always compiled with host gcc.
> > > If host gcc version is lessthan 7 and target gcc is greaterthan 7
> > > pmdinfogen fails to compile due to unsupported cflags.
> > > This patch removes unsupported host cflags when the above condition is
> > > met.
> > > 
> > > Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")
> > > Cc: stable@dpdk.org
> > > 
> > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > > ---
> > >  buildtools/pmdinfogen/Makefile | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/buildtools/pmdinfogen/Makefile b/buildtools/pmdinfogen/Makefile
> > > index a97a7648f..86f883e05 100644
> > > --- a/buildtools/pmdinfogen/Makefile
> > > +++ b/buildtools/pmdinfogen/Makefile
> > > @@ -9,6 +9,14 @@ include $(RTE_SDK)/mk/rte.vars.mk
> > >  #
> > >  HOSTAPP = dpdk-pmdinfogen
> > >  
> > > +HOST_GCC_MAJOR = $(shell echo __GNUC__ | $(HOSTCC) -E -x c - | tail -n 1)
> > > +HOST_GCC_MINOR = $(shell echo __GNUC_MINOR__ | $(HOSTCC) -E -x c - | tail -n 1)
> > > +HOST_GCC_VERSION = $(HOST_GCC_MAJOR)$(HOST_GCC_MINOR)
> > > +
> > > +ifeq ($(shell test $(HOST_GCC_VERSION) -gt 70 && echo 1), 1)
> > > +HOST_WERROR_FLAGS = $(filter-out -Wimplicit-fallthrough=2, $(WERROR_FLAGS))
> > > +endif
> > > +
> > 
> > A few things:
> > 
> > 1) HOST_GCC_MAJOR and HOST_GCC_MINOR seem to already be computed in
> > rte.toolchain-compat.mk and so I don't think you need to recompute them here
> > 
> > 2) This seems limited in its function.  That is to say, ostensibly there are
> > simmilar incompatibilities with icc and clang that may need addressing for which
> > there are different environment variables (CLANG_MAJOR_VERSION, etc)
> > 
> > 3) This may also need to be reflected into the meson build environment
> 
> Initially I though that meson cross-compilation support would make this a
> non-issue, but looking into it further it could theoretically be a problem
> with meson too. Where the issue would arise is where we use
> "add_project_arguments()" in "config/meson.build" for the cflags. When
> adding those flags we only check the standard compiler, which would be the
> cross-compiler in the cross compilation case. Unfortunately, I don't
> believe that meson supports setting project options only for native or
> non-native compiles - it assumes that per-project arguments are really
> global to that whole project, and expect you to specify them per-target if
> not.
> 
> To fix this possible issue for cross-compilation, what we really need to do
> in to get the native compiler too (using "meson.get_compiler('c', native:
> 'true')") and check that the cflags are valid for it also. In case of a
> flag that is supported by one compiler but not the other, the flag would be
> omitted, which means that instead of a compiler error we should instead get
> an error with reduced warning flags. (I'm assuming that it's only the
> warnings need adjusting here - any compiler that doesn't support
> "-D<define>" syntax just won't work anyway, I suspect :-))
> 
> I'll see if I can do up a quick patch to fix this for meson.
> 
Actually, looks like I sent the reply too quickly and I may be incorrect here.

Checking the build.ninja file for a cross-build for arm64-armv8, I already
see different flags for pmdinfogen and other objects, so looks to me like no
issue after all. [This is with meson v0.51].

/Bruce

  reply	other threads:[~2019-07-31 14:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31  6:27 pbhagavatula
2019-07-31 11:35 ` Neil Horman
2019-07-31 14:21   ` Bruce Richardson
2019-07-31 14:30     ` Bruce Richardson [this message]
2019-07-31 14:31 ` Bruce Richardson
2019-08-02  3:35   ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190731143037.GE1705@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=nhorman@tuxdriver.com \
    --cc=pbhagavatula@marvell.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).