21/06/2021 10:28, David Marchand:

On Fri, Jun 18, 2021 at 3:41 PM Andrew Rybchenko

quoted

+# 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.