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 3B7A9A0A0C; Fri, 2 Jul 2021 14:53:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EAED941353; Fri, 2 Jul 2021 14:53:13 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 0372C40686 for ; Fri, 2 Jul 2021 14:53:11 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 75D9D7F528; Fri, 2 Jul 2021 15:53:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 75D9D7F528 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1625230391; bh=wyxMIM/JLhC6ohxH7WBWQU9g2QgsquyveCaR3UtI7gg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=GepYz5I51YEAFxI0yQljyqW28d/RoF9VgxArD2SQULiSBrHtgwOOvSIL7/ftA1zHG bvJGIhk5Be/f3UTTEQ6icqDYszAsLqno6TiZwpzxO2or+k9wDJ2x7nVbXFdIosiJKI Ra9v+l9TRE957WD/ddN9pp/B3rkWxuIWJTBoCqR4= To: Thomas Monjalon , David Marchand , Bruce Richardson Cc: dev , Igor Romanov , Andy Moreton , Ivan Malov References: <20210527152510.1551026-1-andrew.rybchenko@oktetlabs.ru> <0704be2b-674b-5e04-2c0e-ad8b0c528bf5@oktetlabs.ru> <10487590.FxHezTWy5a@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <296e71af-1b8d-b306-dc2f-c476c7a44cce@oktetlabs.ru> Date: Fri, 2 Jul 2021 15:53:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <10487590.FxHezTWy5a@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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" On 7/2/21 3:30 PM, Thomas Monjalon wrote: > 02/07/2021 10:43, Andrew Rybchenko: >> On 7/1/21 4:05 PM, Andrew Rybchenko wrote: >>> On 7/1/21 3:34 PM, David Marchand wrote: >>>> On Thu, Jul 1, 2021 at 11:22 AM Andrew Rybchenko >>>> wrote: >>>>> The build works fine for me on FC34, but it has >>>>> libatomic-11.1.1-3.fc34.x86_64 installed. >>>> >>>> I first produced the issue on my "old" FC32. >>>> Afaics, for FC33 and later, gcc now depends on libatomic and the >>>> problem won't be noticed. >>>> FC32 and before are EOL, but I then reproduced the issue on RHEL 8 >>>> (and Intel CI reported it on Centos 8 too). >>> >>> I see. Thanks for the clarification. >>> >>>>> >>>>> I'd like to understand what we're trying to solve here. >>>>> Are we trying to make meson to report the missing library >>>>> correctly? >>>>> >>>>> If so, I think I can do simple check using cc.links() >>>>> which will fail if the library is not found. I'll >>>>> test that it works as expected if the library is not >>>>> completely installed. >>>>> >>>> >>>> I tried below diff, and it works for me. >>>> "works" as in net/sfc gets disabled without libatomic installed: > [...] >>>> # for gcc compiles we need -latomic for 128-bit atomic ops >>>> if cc.get_id() == 'gcc' >>>> + code = '''#include >>>> + void main() { printf("Atomilink me.\n"); } >>>> + ''' >>>> + if not cc.links(code, args: '-latomic', name: 'libatomic link check') >>>> + build = false >>>> + reason = 'missing dependency, "libatomic"' >>>> + subdir_done() >>>> + endif >>>> ext_deps += cc.find_library('atomic') >>>> endif >>> >>> Many thanks, LGTM. I'll pick it up and add comments why >>> it is checked this way. >>> >> >> I've send v4 with the problem fixed. However, I'm afraid >> build test systems should be updated to have libatomic >> correctly installed. Otherwise, they do not really check >> net/sfc build. > > When testing on old systems, sfc won't be tested anymore after this patchset. > On recent systems, sfc should be enabled I guess. > I don't see how to manage better, sorry. > I see. I thought that it is possible to install missing package on corresponding systems to make build coverage better. Now I automatically test build on problematic distros with previously missing packages installed. So I have internal build coverage anyway.