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
>>>> <andrew.rybche...@oktetlabs.ru> 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 <stdio.h>
>>>> + 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.
