From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id D79245F62 for ; Wed, 13 Feb 2019 12:48:27 +0100 (CET) Received: by mail-wr1-f66.google.com with SMTP id l5so1060346wrw.6 for ; Wed, 13 Feb 2019 03:48:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=bOyGP07UsQCzqqFFE0Z692vVwTy4RdeAfsEl4nE2bX4=; b=NO0e3dMsPsZUNwSVy/i5WJgpapV3dRJA1/4/rson8C/ymO2L76RabrBCgvRj8IextJ 2bm4eM+aeNSJ3SnmaS1uKCWNirBwVMmcnsb1oS3lza5Z7qCkE8XNwyyxRkg/rjQCKEiI KyYV+K7BAr0EJTYZnv7UbSRO4q7MHnBkeSptJw1ziv5K/+inutj7WcEPgfCrKUPDdoUr epZ5+YRvE2s763YdTxXCRdQhfZ4TY1DeL9gCKDbw0RrQVYCjXd4reMCNKk+07zSzW2kt H/C37Qli/gcyadPWMGxBdV9GlR9LdBmvvDtE8xO9hwHA6CyT+jZMv6gi9gOtkS9F9Wm1 a1tQ== X-Gm-Message-State: AHQUAua7o3BNVIuT8YX/5LVn4IDz77GETFoWLV/EJ4DilmA9pft5NJ2U vpR/imc9xBiFWTJHer0/IBw= X-Google-Smtp-Source: AHgI3IbJ1pRK9ASUYZCzb3BFhbH+OZ7RDC8I00y0x0vEGjmerG2ucBztJqOOLfHz5T16XVsNZqPJNg== X-Received: by 2002:adf:e2c8:: with SMTP id d8mr79324wrj.228.1550058507364; Wed, 13 Feb 2019 03:48:27 -0800 (PST) Received: from localhost ([2a01:4b00:f419:6f00:c934:57a:5587:ac0c]) by smtp.gmail.com with ESMTPSA id h71sm13729335wme.20.2019.02.13.03.48.26 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 13 Feb 2019 03:48:26 -0800 (PST) Message-ID: <1550058506.4818.8.camel@debian.org> From: Luca Boccassi To: Thomas Monjalon , Bruce Richardson Cc: dev@dpdk.org Date: Wed, 13 Feb 2019 11:48:26 +0000 In-Reply-To: <1550054983.4818.3.camel@debian.org> References: <20190103175725.5836-1-bluca@debian.org> <2701171.9Cy1FB2YhE@xps> <20190212150318.GC517812@bricha3-MOBL.ger.corp.intel.com> <3052011.MRUk6sNC2W@xps> <1550054983.4818.3.camel@debian.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 2/5] build: use dependency() instead of find_library() 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: Wed, 13 Feb 2019 11:48:28 -0000 On Wed, 2019-02-13 at 10:49 +0000, Luca Boccassi wrote: > On Tue, 2019-02-12 at 17:21 +0100, Thomas Monjalon wrote: > > 12/02/2019 16:03, Bruce Richardson: > > > On Tue, Feb 12, 2019 at 03:47:56PM +0100, Thomas Monjalon wrote: > > > > 12/02/2019 12:43, Bruce Richardson: > > > > > On Tue, Feb 12, 2019 at 12:36:17PM +0100, Thomas Monjalon > > > > > wrote: > > > > > > 12/02/2019 12:31, Bruce Richardson: > > > > > > > On Tue, Feb 12, 2019 at 12:15:43PM +0100, Thomas Monjalon > > > > > > > wrote: > > > > > > > > 06/02/2019 18:08, Luca Boccassi: > > > > > > > > > Whenever possible (if the library ships a pkg-config > > > > > > > > > file) use meson's > > > > > > > > > dependency() function to look for it, as it will > > > > > > > > > automatically add it > > > > > > > > > to the Requires.private list if needed, to allow for > > > > > > > > > static builds to > > > > > > > > > succeed for reverse dependencies of DPDK. Otherwise > > > > > > > > > the > > > > > > > > > recursive > > > > > > > > > dependencies are not parsed, and users doing static > > > > > > > > > builds have to > > > > > > > > > resolve them manually by themselves. > > > > > > > > > When using this API avoid additional checks that are > > > > > > > > > superfluous and > > > > > > > > > take extra time, and avoid adding the linker flag > > > > > > > > > manually which causes > > > > > > > > > it to be duplicated. > > > > > > > > >=20 > > > > > > > > > Signed-off-by: Luca Boccassi > > > > > > > > > Acked-by: Bruce Richardson > > > > > > > > m> > > > > > > > >=20 > > > > > > > > This patch breaks compilation on my machine with a lot > > > > > > > > of > > > > > > > > strange errors: > > > > > > > >=20 > > > > > > > > from drivers/net/pcap/rte_eth_pcap.c > > > > > > > >=20 > > > > > > > > /usr/include/stdint.h:109: error: "__INT64_C" redefined > > > > > > > > /usr/include/bits/stdlib-bsearch.h:32:13: error: cast > > > > > > > > discards 'const' qualifier from pointer target type > > > > > > > > /usr/include/pthread.h:682:6: error: 'regparm' > > > > > > > > attribute > > > > > > > > directive ignored > > > > > > > > etc > > > > > > > >=20 > > > > > > >=20 > > > > > > > Is this on Arch linux again? I just reverified these > > > > > > > first > > > > > > > two patches and > > > > > > > they work fine for me on Fedora (I assume Luca probably > > > > > > > tested them already on > > > > > > > Debian)=C2=A0 > > > > > > >=20 > > > > > > > Anything unusual about your setup? > > > > > >=20 > > > > > > Nothing unusual. Just using the best environment ever ;) > > > > > > I will try to debug it. > > > > > >=20 > > > > >=20 > > > > > It may be something pcap-specific, since pcap has to have > > > > > it's > > > > > own special > > > > > query mechanims outside the normal pkg-config one. If you > > > > > remove the > > > > > pcap-driver changes, does the rest of the patch work for you? > > > >=20 > > > > Yes, the issue happens only with pcap on Arm. > > > > Reverting the pcap related changes, it builds fine. > > > >=20 > > > > More infos about my setup: > > > > meson-0.49.1 > > > > aarch64-linux-gnu-gcc-8.2.0 > > > > libpcap-1.9.0 (32 and 64-bit) for x86 > > > >=20 > > > > I think there is a mix between libcap for x86 and Arm > > > > compilation. > > > > Probably a meson bug? > > > >=20 > > >=20 > > > Could well be a meson issue. It may be using the local pcap- > > > config > > > rather > > > than the cross-compilation version [assuming cross-compilation > > > here, though > > > I don't see the issue with my setup]. > > >=20 > > > Thomas, can you apply this set with the pcap driver change > > > dropped, > > > or is it better if Luca does a new version of this set? > >=20 > > I think we need a comment about the pcap miss. > > Probably better to do a new version. > >=20 > > Luca, please could you test cross-compilation? >=20 > Hi, >=20 > I would, except downloading the toolchain from Linaro fails with 403 > forbidden... >=20 > https://releases.linaro.org/components/toolchain/binaries/latest/aarc > h64-linux-gnu/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux- > gnu.tar.xz >=20 > I'll try with Debian's cross compiler I think the issue is that I'm going in circles: https://git.dpdk.org/dpdk/commit/?id=3Dd1e4a5b7320905f025e7caea685708b5eea3= 7456 https://git.dpdk.org/dpdk/commit/?id=3D6930c0403a1754eb5cab89577565eefa5a99= 95a1 As Bruce said, the root cause is libpcap's lack of a pkg-config file and usage of a custom tool, which is a known bane for cross compilers. The good news is that 1.9.0 finally added a pkg-config file in addition: https://github.com/the-tcpdump-group/libpcap/commit/a7deb6a241f8c71ca261adc= 45ac07c8427074792 Given cross-compilation doesn't work at all for me, I'll do a v7 without th= at snippet. --=20 Kind regards, Luca Boccassi