DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] test-meson-builds: add 32-bit compilation test
Date: Thu, 11 Oct 2018 14:46:38 +0100	[thread overview]
Message-ID: <20181011134637.GA7576@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <14672842.gTEYPIatuu@xps>

On Thu, Oct 11, 2018 at 01:54:58PM +0200, Thomas Monjalon wrote:
> 18/09/2018 12:23, Thomas Monjalon:
> > 18/09/2018 12:15, Bruce Richardson:
> > > On Mon, Sep 17, 2018 at 09:58:59PM +0200, Thomas Monjalon wrote:
> > > > 17/09/2018 21:34, Bruce Richardson:
> > > > > On Mon, Sep 17, 2018 at 06:44:52PM +0200, Thomas Monjalon wrote:
> > > > > > 17/09/2018 17:17, Bruce Richardson:
> > > > > > > On Mon, Sep 17, 2018 at 03:38:58PM +0200, Thomas Monjalon wrote:
> > > > > > > > 17/09/2018 14:54, Bruce Richardson:
> > > > > > > > > On Mon, Sep 17, 2018 at 02:03:50PM +0200, Thomas Monjalon wrote:
> > > > > > > > > > 29/08/2018 18:02, Bruce Richardson:
> > > > > > > > > > > Add in a cross-file to enable 32-bit compile tests as part
> > > > > > > > > > > of the test-meson-builds script.
> > > > > > > > > > > 
> > > > > > > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > > > > > > ---
> > > > > > > > > > > NOTE: For ease of use, it's recommended that meson 0.47 be used for
> > > > > > > > > > > this testing. With earlier versions, it may be necessary to ensure that
> > > > > > > > > > > the same development packages are installed for both 64-bit and 32-bit.
> > > > > > > > > > > ---
> > > > > > > > > > >  config/x86/i686_sse4_linuxapp_gcc | 18 ++++++++++++++++++
> > > > > > > > > > >  devtools/test-meson-builds.sh     |  4 ++++
> > > > > > > > > > >  2 files changed, 22 insertions(+)
> > > > > > > > > > 
> > > > > > > > > > I'm not sure about adding this test as mandatory, because 32-bit version
> > > > > > > > > > of libraries can be hard to get, especially libbsd and libnuma.
> > > > > > > > > > I hope this test will be run by all developers, so we should not discourage
> > > > > > > > > > them by adding too many requirements.
> > > > > > > > > > Opinion? Idea?
> > > > > > > > > 
> > > > > > > > > Libbsd is not required, but yes, libnuma is, so you do need a 32-bit
> > > > > > > > > libnuma (devel) installed to run this test. I would expect that to be
> > > > > > > > > available on most distros though. I'm open to suggestions as to how to make
> > > > > > > > > this optional, but I do think that sanity checking 32-bit is good practice
> > > > > > > > > to avoid errors, e.g. those wonderful printf format strings for uint64_t.*
> > > > > > > > 
> > > > > > > > I agree and I am testing i686 with the "make build system".
> > > > > > > > I define DPDK_DEP_NUMA=n which disables any NUMA option.
> > > > > > > > Can we have this kind of tweak with meson?
> > > > > > > > 
> > > > > > > > Or perhaps we can just have an option in the script to disable this test?
> > > > > > > > 
> > > > > > > Actually, do you see build failures with 32-bit without the numa or BSD
> > > > > > > libraries? I removed 32-bit versions of both dev packages and everything
> > > > > > > still compiles? The setting of the appropriate defines is based on detected
> > > > > > > libraries.
> > > > > > 
> > > > > > This is what I see:
> > > > > > 
> > > > > > ninja -C build-i686
> > > > > > ninja: Entering directory `build-i686'
> > > > > > [6/1237] Linking target lib/librte_kvargs.so.1.1.
> > > > > > FAILED: lib/librte_kvargs.so.1.1 
> > > > > > gcc  -o lib/librte_kvargs.so.1.1 'lib/lib@@rte_kvargs@sta/librte_kvargs_rte_kvargs.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname,librte_kvargs.so.1 -pthread -lm -ldl -lnuma -lbsd -Wl,--end-group -Wl,--version-script=lib/librte_kvargs/rte_kvargs_version.map -m32 
> > > > > > /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../libnuma.so when searching for -lnuma
> > > > > > /usr/bin/ld: skipping incompatible /usr/lib/libnuma.so when searching for -lnuma
> > > > > > /usr/bin/ld: cannot find -lnuma
> > > > > > /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../libbsd.so when searching for -lbsd
> > > > > > /usr/bin/ld: skipping incompatible /usr/lib/libbsd.so when searching for -lbsd
> > > > > > /usr/bin/ld: cannot find -lbsd
> > > > > > collect2: error: ld returned 1 exit status
> > > > > > [11/1237] Compiling C object 'lib/lib@@rte_eal@sta/librte_eal_common_eal_common_fbarray.c.o'.
> > > > > > ninja: build stopped: subcommand failed.
> > > > > > 
> > > > > What version of meson are you using? As the comment in the file suggests,
> > > > > 0.47 is really needed for sane behaviour, as before then meson could
> > > > > sometimes pick up 64-bit static libs and use them for 32-bit compilation.
> > > > > [Being static libs makes them rather hard to test if they are usable since
> > > > > the .a file itself doesn't provide that info, unlike for a .so]. So for
> > > > > 0.46 or earlier, you can still build, but you probably need 32-bit versions
> > > > > of your 64-bit dev packages installed.
> > > > 
> > > > I am using meson 0.47.2
> > > > Is there a bug somewhere?
> > > > 
> > > Possibly.
> > > Let's leave out the patch for now and I'll try and investigate further.
> > > What OS distro are you using, so I can try and reproduce the issue?
> > 
> > I am using archlinux.
> > 
> > Thanks for investigating.
> 
> I switched to meson 0.48.0, and I still have this error unfortunately:
> 
> /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../libnuma.so when searching for -lnuma
> /usr/bin/ld: skipping incompatible /usr/lib/libnuma.so when searching for -lnuma
> /usr/bin/ld: cannot find -lnuma
> /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../libbsd.so when searching for -lbsd
> /usr/bin/ld: skipping incompatible /usr/lib/libbsd.so when searching for -lbsd
> /usr/bin/ld: cannot find -lbsd
> collect2: error: ld returned 1 exit status
>

Apologies, it was my mistake asking for a re-test on 0.48. I thought the
fix for this was merged into 0.48, but checking the git log it appears it
was merged shortly after that release. I'll make more sure in future.

/Bruce

      reply	other threads:[~2018-10-11 13:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 16:02 Bruce Richardson
2018-09-17 12:03 ` Thomas Monjalon
2018-09-17 12:54   ` Bruce Richardson
2018-09-17 13:38     ` Thomas Monjalon
2018-09-17 15:17       ` Bruce Richardson
2018-09-17 16:44         ` Thomas Monjalon
2018-09-17 19:34           ` Bruce Richardson
2018-09-17 19:58             ` Thomas Monjalon
2018-09-18 10:15               ` Bruce Richardson
2018-09-18 10:23                 ` Thomas Monjalon
2018-10-11 11:54                   ` Thomas Monjalon
2018-10-11 13:46                     ` Bruce Richardson [this message]

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=20181011134637.GA7576@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    /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).