test-meson-builds: add 32-bit compilation test

  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(+)
 create mode 100644 config/x86/i686_sse4_linuxapp_gcc
  

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?
  

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.

/Bruce
  

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?
  

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.

/Bruce
  

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.
  

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.

/Bruce
  

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?
  

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?

/Bruce
  

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.
  

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
  

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