When you say meson can, what to you mean? I thought meson didn't support tinycc.

Right now muon gets the list of dirs to search through via cc --print-search-dirs, which isn't posix. There should maybe be a fallback like get_option('prefix') / get_option('libdir')?

Ah, we use our patched fork for that: https://github.com/ret2libc/meson.git There was a PR (https://github.com/mesonbuild/meson/pull/8248) to meson but it was never accepted, so we decided it will be easier to just completely move to Muon for this configuration.

@lattis according to https://bellard.org/tcc/tcc-doc.html#Option-summary there is -print-search-dirs (note the single -)

@~xvilka look at line 316 in compiler.c:

https://git.sr.ht/~lattis/muon/tree/master/item/src/compilers.c#L313

you can try to fix tinycc here with the correct option to pass to tinycc.

There are 2 ways to fix this, both are valid

1. patch tcc to accept -print-search-dirs & --print-search-dirs (recommended)
2. patch muon to append -print-search-dirs

All GCC versions accept both -print-search-dirs & --print-search-dirs (tested gcc4.7, gcc5 & gcc11), but only -print-search-dirs is canonical according to the help msg

gcc 4.7

# i486-slackware-linux-gcc --help | grep print
  -print-search-dirs       Display the directories in the compiler's search path
  -print-libgcc-file-name  Display the name of the compiler's companion library
  -print-file-name=<lib>   Display the full path to library <lib>
  -print-prog-name=<prog>  Display the full path to compiler component <prog>
  -print-multi-directory   Display the root directory for versions of libgcc
  -print-multi-lib         Display the mapping between command line options and
  -print-multi-os-directory Display the relative path to OS libraries
  -print-sysroot           Display the target libraries directory
  -print-sysroot-headers-suffix Display the sysroot suffix used to find headers

gcc 11.2

# ./i686-linux-musl-gcc --help | grep print
  -print-search-dirs       Display the directories in the compiler's search path.
  -print-libgcc-file-name  Display the name of the compiler's companion library.
  -print-file-name=<lib>   Display the full path to library <lib>.
  -print-prog-name=<prog>  Display the full path to compiler component <prog>.
  -print-multiarch         Display the target's normalized GNU triplet, used as
  -print-multi-directory   Display the root directory for versions of libgcc.
  -print-multi-lib         Display the mapping between command line options and
  -print-multi-os-directory Display the relative path to OS libraries.
  -print-sysroot           Display the target libraries directory.
  -print-sysroot-headers-suffix Display the sysroot suffix used to find headers.

clang also supports -print-search-dirs

This should be enough to fix this issue, it's the correct GCC parameter, it should work with all compilers that implement some GCC compatibility

diff --git a/src/compilers.c b/src/compilers.c
index 4815ab0e..cae3ae91 100644
--- a/src/compilers.c
+++ b/src/compilers.c
@@ -313,7 +313,7 @@ static bool
 compiler_get_libdirs(struct workspace *wk, struct obj_compiler *comp)
 {
 	struct run_cmd_ctx cmd_ctx = { 0 };
-	if (!run_cmd_arr(wk, &cmd_ctx, comp->cmd_arr, "--print-search-dirs")
+	if (!run_cmd_arr(wk, &cmd_ctx, comp->cmd_arr, "-print-search-dirs")
 	    || cmd_ctx.status) {
 		goto done;
 	}

But that's only one issue, I found that muon apparently doesn't check compiler options and just adds stuff that breaks older GCC compilers, and other compilers

cc: error: unrecognized command line option ‘-fdiagnostics-color=always’
samu: subcommand failed

I also found compilation issues with older libarchive versions. The minimum supported version is probably 3.2, but I can confirm that 3.3 works ok

Changed to pass -print-search-dirs. ~xvilka, can you confirm this fixes the tcc issue?

~lattis, sorry, still didn't help: https://github.com/rizinorg/rizin/actions/runs/7076647158/job/19260119164?pr=3345#step:9:73

~lattis, I retried again with latest Muon and TCC commits and the problem is still the same. Do you know what might be the reason?

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 ?

Ok, thanks to ~vtorri, it was found that this problem happens when CC is set in environment prior to calling muon, e.g. env CC=tcc muon setup build but 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 how muon picks up environment variables.

Related rizin issue: https://github.com/rizinorg/rizin/pull/3345