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.
