Problems with building using meson and fuzzing

[Jon Maloy]

Alex, Stefan & al
I am trying to build and run Marc-Andrés Lureaus libslirp code with 
fuzzing activated, but I am running into build issues.
https://gitlab.freedesktop.org/elmarco/libslirp/-/commit/9fba8af484ec6bc10b22e3f49d9e34d95c28b086
Since I am new to meson I thought it might be quicker to ask somebody 
instead of spending a lot of time on this myself.

1: I cloned the repository.
2: I made a "regular" build as you suggested in the mommit log, using 
gcc, and made a run. No problem.
3: I then try to build using clang and with fuzzing activated, also as 
suggested in the commit log:
[jmaloy@f31 libslirp]$ CFLAGS="-fsanitize=fuzzer" CC=clang CXX=clang++  
meson build-clang -Db_lundef=false
(*** Note that the build directory is missing in the commit log's 
example command)
The Meson build system
Version: 0.55.3
Source dir: /home/jmaloy/fuzzing/lureau/libslirp
Build dir: /home/jmaloy/fuzzing/lureau/libslirp/build-clang
Build type: native build
Project name: slirp
Project version: 4.0.0
Using 'CC' from environment with value: 'clang'
Using 'CFLAGS' from environment with value: '-fsanitize=fuzzer'

meson.build:1:0: ERROR: Compiler clang can not compile programs.

A full log can be found at 
/home/jmaloy/fuzzing/lureau/libslirp/build-clang/meson-logs/meson-log.txt
[jmaloy@f31 libslirp]$


The content of the indicated log file:
------------------------------------------------
Build started at 2020-09-17T19:04:23.217850
Main binary: /usr/bin/python3
Build Options: -Db_lundef=false
Python system: Linux
The Meson build system
Version: 0.55.3
Source dir: /home/jmaloy/fuzzing/lureau/libslirp
Build dir: /home/jmaloy/fuzzing/lureau/libslirp/build-clang
Build type: native build
None of 'PKG_CONFIG_PATH' are defined in the environment, not changing 
global flags.
None of 'PKG_CONFIG_PATH' are defined in the environment, not changing 
global flags.
Project name: slirp
Project version: 4.0.0
Using 'CC' from environment with value: 'clang'
Using 'CFLAGS' from environment with value: '-fsanitize=fuzzer'
None of 'LDFLAGS' are defined in the environment, not changing global flags.
None of 'CPPFLAGS' are defined in the environment, not changing global 
flags.
None of 'CC_LD' are defined in the environment, not changing global flags.
Sanity testing C compiler: clang
Is cross compiler: False.
None of 'CC_LD' are defined in the environment, not changing global flags.
Sanity check compiler command line: clang 
/home/jmaloy/fuzzing/lureau/libslirp/build-clang/meson-private/sanitycheckc.c 
-o 
/home/jmaloy/fuzzing/lureau/libslirp/build-clang/meson-private/sanitycheckc.exe 
-fsanitize=fuzzer -pipe -D_FILE_OFFSET_BITS=64
Sanity check compile stdout:

-----
Sanity check compile stderr:
/usr/bin/ld: /tmp/sanitycheckc-689218.o: in function `main':
sanitycheckc.c:(.text.main[main]+0x0): multiple definition of `main'; 
/usr/lib64/clang/9.0.1/lib/linux/libclang_rt.fuzzer-x86_64.a(FuzzerMain.cpp.o):(.text.startup[.text.startup.group]+0x0): 
first defined here
/usr/bin/ld: 
/usr/lib64/clang/9.0.1/lib/linux/libclang_rt.fuzzer-x86_64.a(FuzzerMain.cpp.o): 
in function `main':
(.text.startup[.text.startup.group]+0xf): undefined reference to 
`LLVMFuzzerTestOneInput'
clang-9: error: linker command failed with exit code 1 (use -v to see 
invocation)

-----

meson.build:1:0: ERROR: Compiler clang can not compile programs.

My environment:
----------------------
[jmaloy@f31 libslirp]$ which clang
/usr/bin/clang
[jmaloy@f31 libslirp]$ clang --version
clang version 9.0.1 (Fedora 9.0.1-2.fc31)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
[jmaloy@f31 libslirp]$ which meson
~/.local/bin/meson
[jmaloy@f31 libslirp]$ meson --version
0.55.3
[jmaloy@f31 libslirp]$

I updated from meson 0.52.0 to 0.55.3, but the result is exactly the same.
I commented out "main()" in fuzz-main.c  just to check, but that is not 
the issue of course.
To me it looks like the sanity checker is trying to link to 
libclang_rt.fuzzer-x86_64.a  twice, and at the same time is incapable of 
finding LLVMFuzzerTestOneInput() which clearly is there.

Does anybody have any ideas about this?

BR
///Jon Maloy