From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 032AB1B580 for ; Thu, 11 Oct 2018 13:55:00 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 86D6721FFF; Thu, 11 Oct 2018 07:55:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 11 Oct 2018 07:55:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=Ux5MkWgu73Jn8K4M67U7BAWmii7Rdi3ZHTMsx5zJXes=; b=MyaUxtrIzFsa Gr7yGxgJvGmQepcp++Wf8gHMMie4TCHPgGhj4NHU35VeORHT+77lH1j7X3htLjWn 4xx8AlkNLh5gxpPIkf+Ex7zqGFp1/5RFIcYlT0rXbXh3oAwVgkDO4VzhiB3dv0cQ 4KdBDa8HNbMM+hd01OLXbvVlXEZKO5A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Ux5MkWgu73Jn8K4M67U7BAWmii7Rdi3ZHTMsx5zJX es=; b=q7cXEpEel4Yn4/eEFVEcY9Skexs+2JolPsSZdi7h05HaNJLbuz5CMLCtN C+JyHBzjVW504qTm38n8HVqmiWtUgwRoNBHGDlPNmvnjDms6ZwUTg49L0Da5aJyt oH0ldGEdv1ZdVhs5Nqvoyr34GtV9LUAlp7M2DiJE8gu8IbO3YTI4xsxRdPLo/ZZK cFIoque00t7UHcHZDlin0Ly0Xmn8UlYkfF5dkAj0WAJt5AfgNubGKHDF1oWrrh29 QCeOaTJg14sBlv5+JarfMlkwkAp/mIEXlwvGidgRekeBaK/1Xt0AUBT1O6fVYjol ej9SlenujOnFnMRZP6CPLKxOvcWCg== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A1982E4625; Thu, 11 Oct 2018 07:54:59 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org Date: Thu, 11 Oct 2018 13:54:58 +0200 Message-ID: <14672842.gTEYPIatuu@xps> In-Reply-To: <3714019.paGayHj6og@xps> References: <20180829160252.7890-1-bruce.richardson@intel.com> <20180918101458.GA14824@bricha3-MOBL.ger.corp.intel.com> <3714019.paGayHj6og@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] test-meson-builds: add 32-bit compilation test X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 11:55:01 -0000 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 > > > > > > > > > > --- > > > > > > > > > > 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