wasm-mutator-fuzz: make compilers overridable

[yamt]

eg.

cmake .. \
-DCMAKE_C_COMPILER=/usr/local/opt/llvm@15/bin/clang \
-DCMAKE_CXX_COMPILER=/usr/local/opt/llvm@15/bin/clang++

[lum1n0us]

✋ there will be a problem if both CC and CXX have been set to gcc and g++ which usually happens in linux because use GCC as the default compiler and CMAKE_<LANG>_COMPILER always point to CC and CXX.

After the PR, it requires

• Either use clang/clang++ as the default compiler by setting CC and CXX.
• Or always switch to clang manually, like CC=$(which clang) CXX=$(which clang++) cmake -S . -B build

Anyway, the previous, simplest command cmake -S . -B build && cmake --build build may lead to

cc: error: unrecognized argument to ‘-fsanitize=’ option: ‘fuzzer’
cc: error: unrecognized argument to ‘-fsanitize=’ option: ‘unsigned-integer-overflow’; did you mean ‘signed-integer-overflow’?
cc: error: unrecognized argument to ‘-fsanitize=’ option: ‘local-bounds’
cc: error: unrecognized argument to ‘-fsanitize=’ option: ‘nullability’
cc: error: unrecognized command-line option ‘-fprofile-instr-generate’; did you mean ‘-fprofile-generate’?
cc: error: unrecognized command-line option ‘-fcoverage-mapping’

[yamt]

✋ there will be a problem if both CC and CXX have been set to gcc and g++ which usually happens in linux because use GCC as the default compiler and CMAKE_<LANG>_COMPILER always point to CC and CXX.

do you mean environment variables CC and CXX are set system-wide by default? are you sure it "usually happens in linux"? i don't remember such distributions.

[lum1n0us]

Maybe "usually" is a strong word(depends on how to setup the machine. Personal habits). But I found two available machines around me sharing the same problem because using the GCC as default compiler and ENV(CC) points to /usr/bin/cc points to gcc

[yamt]

if a user sets CC explicitly and it broke things, i feel it's his problem. besides that, even clang doesn't always come with libfuzzer. i suspect there is no magic which works on every environment. maybe the best thing we can do here is to document the requirement.

[lum1n0us]

I am thinking about following the original intention, forcing Clang compiler. It may like:

# STREQUAL or MATCH 
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
  set(CMAKE_CXX_COMPILER "clang")
endif ()

[yamt]

I am thinking about following the original intention, forcing Clang compiler. It may like:

# STREQUAL or MATCH 
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
  set(CMAKE_CXX_COMPILER "clang")
endif ()

it doesn't work if your clang doesn't ship with libfuzzer. unfortunately it isn't too uncommon.

[lum1n0us]

The problem is if not defined values(of CMAKE_C_COMPILER and CMAKE_CXX_COMPILER) in command line options, if (NOT DEFINED) ... set ... will not work. It will use values of ENV(CC) and ENV(C++).

It means the modification actually won't be executed. It's not make options overridable. It requires users always give compiler info explicitly.

[yamt]

The problem is if not defined values(of CMAKE_C_COMPILER and CMAKE_CXX_COMPILER) in command line options, if (NOT DEFINED) ... set ... will not work. It will use values of ENV(CC) and ENV(C++).

It means the modification actually won't be executed. It's not make options overridable. It requires users always give compiler info explicitly.

i feel we are talking past each other.

if a user specified a compiler explicitly (either via CMAKE_C_COMPILER or CC) it should be used. if a user didn't specify a compiler explicitly, "clang" is used.

[lum1n0us]

if a user didn't specify a compiler explicitly, "clang" is used.

It won't. if (NOT DEFINED CMAKE_C_COMPILER) seems always return FALSE. CMake will detect compilers at the very beginning of.

[yamt]

if a user didn't specify a compiler explicitly, "clang" is used.

It won't. if (NOT DEFINED CMAKE_C_COMPILER) seems always return FALSE. CMake will detect compilers at the very beginning of.

good point. my suggested fix: https://github.com/bytecodealliance/wasm-micro-runtime/pull/3585