Ok, thanks to ~vtorri, it was found that this problem happens when
CCis set in environment prior to callingmuon, e.g.env CC=tcc muon setup buildbut this problem doesn't happen if we set it through muon itself:muon -Denv.CC=tcc setup build. Quite strange. So I guess the real bug is in some difference howmuonpicks up environment variables.
Comment by ~vtorri on ~lattis/muon
btw, minimal support of tcc in muon (proof of concept):
diff --git a/include/compilers.h b/include/compilers.h index 18bd55bb..f3dc3450 100644 --- a/include/compilers.h +++ b/include/compilers.h @@ -25,6 +25,7 @@ struct obj_compiler; _(clang_llvm_ir, "clang", "clang-llvm-ir") \ _(clang_cl, "clang-cl", "clang-cl") \ _(msvc, "msvc", "msvc") \ + _(tcc, "tcc", "tcc") \ _(nasm, "nasm", "nasm") \ _(yasm, "yasm", "yasm") diff --git a/src/compilers.c b/src/compilers.c index 1a79ca87..c4d5fd8d 100644 --- a/src/compilers.c +++ b/src/compilers.c @@ -413,6 +413,8 @@ compiler_detect_c_or_cpp(struct workspace *wk, obj cmd_arr, obj comp_id) } } else if (strstr(cmd_ctx.out.buf, "Free Software Foundation")) { type = compiler_gcc; + } else if (strstr(cmd_ctx.out.buf, "tcc")) { + type = compiler_tcc; } else if (strstr(cmd_ctx.out.buf, "Microsoft") || strstr(cmd_ctx.err.buf, "Microsoft")) { type = compiler_msvc; } else { @@ -1771,6 +1773,12 @@ build_compilers(void) clang_cl.args.enable_lto = compiler_clang_cl_args_lto; clang_cl.default_linker = linker_lld_link; + struct compiler tcc = posix; + tcc.args.optimization = compiler_gcc_args_optimization; + tcc.args.warning_lvl = compiler_gcc_args_warning_lvl; + tcc.args.werror = compiler_gcc_args_werror; + tcc.args.set_std = compiler_gcc_args_set_std; + compilers[compiler_posix] = posix; compilers[compiler_gcc] = gcc; compilers[compiler_clang] = clang; @@ -1778,6 +1786,7 @@ build_compilers(void) compilers[compiler_clang_llvm_ir] = clang_llvm_ir; compilers[compiler_clang_cl] = clang_cl; compilers[compiler_msvc] = msvc; + compilers[compiler_tcc] = tcc; struct compiler nasm = empty; nasm.args.output = compiler_posix_args_output;maybe it can be improved and added in muon ?
Comment by ~vtorri on ~lattis/muon
maybe using valgrind gives another output that could help ?
Comment by ~vtorri on ~lattis/muon
the latest code has fixes for big-endian arch. Try to pull and check again, please
Ticket created by ~vtorri on ~lattis/muon
LD is not used anymore by meson. It's now CC_LD and CXX_LD.
Ticket created by ~vtorri on ~lattis/muon
in machines.c, host_machine and build_machine are the same. So for example, on my Windows 10 64 bits, even if i run the 32 bits Visual Studio prompt (where cl.exe is the 32 bits one), host_machine.address_bits is 64
Ticket created by ~vtorri on ~lattis/muon
strlen() is declared in string.h :
../include/lang/string.h:18:38: warning: implicit declaration of function 'strlen' [-Wimplicit-function-declaration]
this would avoid including <string.h> in files including include/lang/string.h
Ticket created by ~vtorri on ~lattis/muon
since the latest big change in code, this document is out of date
Ticket created by ~vtorri on ~lattis/muon
in compilers.c, guess_version() returns a char* which is always defined, so the test line 249 is useless
Ticket created by ~vtorri on ~lattis/muon
currently, I pass the standard to /std: whatever the standard is. Meson is passing it only if it is c11 or c17 (see https://github.com/mesonbuild/meson/blob/master/mesonbuild/compilers/c.py#L477). Should I do the same for muon ?