[dpdk-dev] [PATCH] test-meson-builds: add 32-bit compilation test

Thomas Monjalon thomas at monjalon.net
Mon Sep 17 18:44:52 CEST 2018


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 at 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 at 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 at sta/librte_eal_common_eal_common_fbarray.c.o'.
ninja: build stopped: subcommand failed.





More information about the dev mailing list