From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A7EA3A0547; Mon, 21 Jun 2021 11:30:53 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1C44741158; Mon, 21 Jun 2021 11:30:53 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 71F4540040 for ; Mon, 21 Jun 2021 11:30:51 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D24665C01A7; Mon, 21 Jun 2021 05:30:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 21 Jun 2021 05:30:50 -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=fm1; bh= RInvtEa0jKCKGBJegchS9ZZW0swTdzYhYmVFGP5pPFw=; b=vC2YbwZxDWX41zQV KJ+x+XdCi6ezRDXgF+r4FmyqC5bcHeolMHGwQOQs6Sa/1WQktuixy6YZ+OYCRQ7n aIJ62CbNRL6S5j6LgPXSDhwGBi3NUCxQJUJC3bihNNbxxJftraZf3Ohg3bMnmhWD dqxb9G/fB3IPF+VMYGN6GsAzNwDGurwN3cFCtlDjVlR0alCYeNAowPlKC41HwOAw 5JylZNUQ01Jnog2O903KAE3oEr8pHfGyU6LQDrk85yGyQgSetpWqGqSTnYG3L+op SzRslSpgjWU/9yjviD5TQpYN7WxZewvK4tAJyf/SO+MHX1QxBxL1wPvg1bslFb+S oKjYWw== 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=fm3; bh=RInvtEa0jKCKGBJegchS9ZZW0swTdzYhYmVFGP5pP Fw=; b=cuHfpAS0H0mMQw6NFy64oNsiA2yknSUwNYS0gnAOUpsnYu9JiE1j93hRk v1jofpp0eQ5G7PJdyacCJfKwoxB5v5/S/2Qzkcs8MsV792Y+3Z5EwEjcHp+vwowK WvIiFvmPnjgJ24vu6Bm9DVvB3ottdUiMEpDtRJoJ4i/EM41VxQOsKeo6+8tH6GJ8 vJc0TvjnYeodC1G6Ox8Y+vyd3mbahvSsyhFhSAUJ+VwggJLdCMluXH7vudqJk3xR 8LobBU9KVwknOjgYnKLjBm+Oo7Pm7uy/Glt2sOz4tPGs4EJGSkH+C9Ly+RhSoGQu 09ulSKGDtwREt2AWd4Msv0bmIlYSA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeefledgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Jun 2021 05:30:47 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko , Bruce Richardson Cc: dev@dpdk.org, Igor Romanov , Andy Moreton , Ivan Malov , David Marchand Date: Mon, 21 Jun 2021 11:30:44 +0200 Message-ID: <23888533.A65Z59arLz@thomas> In-Reply-To: References: <20210527152510.1551026-1-andrew.rybchenko@oktetlabs.ru> <20210618134032.1922012-20-andrew.rybchenko@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 19/20] net/sfc: support flow action COUNT in transfer rules X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 21/06/2021 10:28, David Marchand: > On Fri, Jun 18, 2021 at 3:41 PM Andrew Rybchenko > > +# for gcc compiles we need -latomic for 128-bit atomic ops > > +if cc.get_id() == 'gcc' > > + ext_deps += cc.find_library('atomic') > > +endif > > This patch breaks compilation on rhel/fedora (most failures in UNH for > this series are linked to this issue) when the libatomic rpm is not > installed. [...] > """ > Running compile: > Working directory: > /home/dmarchan/builds/build-gcc-static/meson-private/tmpdu27j15z > Command line: gcc -L/home/dmarchan/intel-ipsec-mb/install/lib > -I/home/dmarchan/intel-ipsec-mb/install/include > /home/dmarchan/builds/build-gcc-static/meson-private/tmpdu27j15z/testfile.c > -o /home/dmarchan/builds/build-gcc-static/meson-private/tmpdu27j15z/output.exe > -pipe -D_FILE_OFFSET_BITS=64 -O0 -Wl,--start-group -latomic > -Wl,--end-group -Wl,--allow-shlib-undefined > > Code: > int main(void) { return 0; } > > Compiler stdout: > > Compiler stderr: > /usr/bin/ld: cannot find /usr/lib64/libatomic.so.1.2.0 > collect2: error: ld returned 1 exit status > > Library atomic found: YES > """ Indeed it looks like a bug in meson. How does it behave with clang 32-bit? For reference, in config/meson.build: """ # for clang 32-bit compiles we need libatomic for 64-bit atomic ops if cc.get_id() == 'clang' and dpdk_conf.get('RTE_ARCH_64') == false atomic_dep = cc.find_library('atomic', required: true) add_project_link_arguments('-latomic', language: 'c') dpdk_extra_ldflags += '-latomic' endif """ > [dmarchan@wsfd-netdev66 dpdk]$ cat > /usr/lib/gcc/x86_64-redhat-linux/10/libatomic.so > INPUT ( /usr/lib64/libatomic.so.1.2.0 ) > [dmarchan@wsfd-netdev66 dpdk]$ file /usr/lib64/libatomic.so.1.2.0 > /usr/lib64/libatomic.so.1.2.0: cannot open > `/usr/lib64/libatomic.so.1.2.0' (No such file or directory) We must handle this case where libatomic is not completely installed. Hope there is a good fix possible.