All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, david.marchand@redhat.com
Subject: Re: [dpdk-dev] [PATCH] devtools: fix 32-bits build
Date: Mon, 09 Nov 2020 14:51:20 +0100	[thread overview]
Message-ID: <107452781.OxjIhUcIOi@thomas> (raw)
In-Reply-To: <20201109133531.GF831@bricha3-MOBL.ger.corp.intel.com>

09/11/2020 14:35, Bruce Richardson:
> On Mon, Nov 09, 2020 at 01:24:28PM +0000, Ferruh Yigit wrote:
> > On 11/9/2020 1:19 PM, Thomas Monjalon wrote:
> > > 09/11/2020 14:00, Ferruh Yigit:
> > > > 32 bit still uses the pkgconfig file for 64-bits libraries, from the
> > > > build log:
> > > > 
> > > > "
> > > > Using DPDK_TARGET i386-pc-linux-gnu
> > > > meson  -Dexamples=l3fwd --buildtype=debugoptimized --werror
> > > > -Dc_args=-m32 -Dc_link_args=-m32
> > > > /tmp/dpdk_maintain/self/dpdk/devtools/.. ./build-32b
> > > > ...
> > > > Using 'PKG_CONFIG_PATH' from environment with value:
> > > > '/usr/local/lib64/pkgconfig/
> > > > "
> > > > 
> > > > This causes build error when linking with the found libraries.
> > > > 
> > > > Reproduced with 'librte_bpf' which only has 64 bit installed but still
> > > > enables building 'af_xdp' and link fails.
> > > 
> > > I think it is a problem in your configuration.
> > > PKG_CONFIG_PATH is not empty before starting the script, right?
> > > 
> > > > To fix updating 'PKG_CONFIG_PATH' and preventing 'load_env' overwrite
> > > > it.
> > > [...]
> > > > 'build-32b' check inside the 'load_env' looks ugly but not sure how to
> > > > be sure 'PKG_CONFIG_PATH' set correct.
> > > [...]
> > > > -	export PKG_CONFIG_PATH=$default_pkgpath
> > > > +	if [ "$targetdir" != "build-32b" ] ; then
> > > > +		export PKG_CONFIG_PATH=$default_pkgpath
> > > > +	fi
> > > 
> > > You can reset PKG_CONFIG_PATH in your config file.
> > > Something like this:
> > > 
> > > if echo $DPDK_TARGET | grep -q '^i[3-6]86' ; then
> > > 	export PKG_CONFIG_PATH=my32bitlibs/pkgconfig
> > > fi
> > > 
> > > We can also discuss why inheriting some default values on script start
> > > instead of just resetting them.
> > > 
> > 
> > Yes I have 'PKG_CONFIG_PATH' set in my environment before running script, if
> > it expects it to be not set, +1 to reset it at the beginning of the script.
> 
> +1 to this, because we can't have a global PKG_CONFIG_PATH for both 32-bit
> and 64-bit builds.

Not sure what is best.
The idea of saving the env vars is to consider what the user set
for one run, not in the config file:

default_path=$PATH
default_pkgpath=$PKG_CONFIG_PATH
default_cppflags=$CPPFLAGS
default_cflags=$CFLAGS
default_ldflags=$LDFLAGS

Do you want to change this assumption to ignore all environment vars?
Should we save PATH at least?
Do we set every variables inside the configuration file?

I tend to think that it may be safer to avoid influence of the env
and have a self-contained config file.
So I would add PATH=/usr/bin at the beginning of my config file.



  reply	other threads:[~2020-11-09 13:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 13:00 [dpdk-dev] [PATCH] devtools: fix 32-bits build Ferruh Yigit
2020-11-09 13:19 ` Thomas Monjalon
2020-11-09 13:24   ` Ferruh Yigit
2020-11-09 13:35     ` Bruce Richardson
2020-11-09 13:51       ` Thomas Monjalon [this message]
2020-11-09 14:55 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2020-11-09 15:28   ` Thomas Monjalon
2020-11-09 15:44     ` Bruce Richardson
2020-11-09 16:14       ` Thomas Monjalon
2020-11-09 16:19         ` Bruce Richardson
2020-11-09 16:48           ` Ferruh Yigit
2020-11-09 17:01             ` Thomas Monjalon
2020-11-09 17:15               ` Ferruh Yigit
2020-11-09 17:20                 ` Thomas Monjalon
2020-11-09 17:44                   ` Thomas Monjalon
2020-11-09 21:02                     ` Thomas Monjalon
2020-11-11 12:34                       ` Ferruh Yigit

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=107452781.OxjIhUcIOi@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.