Comment by ~wdlkmpx on ~lattis/muon
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 failedI 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
Comment by ~wdlkmpx on ~lattis/muon
@variables@were used back in the 90's when autotools was king, and AC_SUBST is used to define custom variables to be replaced globally in all input (.in) files, unknown@variables@are silently ignored or replaced with empty stringsCMake followed the trend and uses the same variables for input (.in) files, unknown
@variables@are replaced with empty strings, doesn't warn about unknown variablesmeson followed the trend and uses the same variables for input (.in) files, unknown
@variables@are replaced with empty strings, warns about unknown variablesI found that this makes muon behave like meson, but haven't tested it thoroughly
diff --git a/src/functions/kernel/configure_file.c b/src/functions/kernel/configure_file.c index 02cde53c..a57573ad 100644 --- a/src/functions/kernel/configure_file.c +++ b/src/functions/kernel/configure_file.c @@ -8,6 +8,7 @@ #include <inttypes.h> #include <string.h> +#include <stdlib.h> #include "args.h" #include "buf_size.h" @@ -117,6 +118,7 @@ substitute_config(struct workspace *wk, uint32_t dict, uint32_t in_node, const c line = 1, start_of_line = 0, id_start_col = 0, id_start_line = 0; obj elem; char tmp_buf[BUF_SIZE_1k] = { 0 }; + char *tmp = NULL; for (i = 0; i < src.len; ++i) { if (src.src[i] == '\n') { @@ -267,8 +269,13 @@ write_mesondefine: error_messagef(&src, id_start_line, id_start_col, log_error, "key of zero length not supported"); return false; } else if (!obj_dict_index_strn(wk, dict, &src.src[id_start], i - id_start, &elem)) { - error_messagef(&src, id_start_line, id_start_col, log_error, "key not found in configuration data"); - return false; + tmp = malloc (i - id_start + 2); + snprintf (tmp, i - id_start + 1, "%s", &src.src[id_start]); + interp_warning(wk, in_node, + "The variable '%s' in the input file '%s' is not present in the given configuration data", tmp, src.label); + free (tmp); + sbuf_pushn(wk, &out_buf, "", 0); + continue; } obj sub;output:
configuring '/mnt/sda3/0git/pkgconf/builddir/tests/test_env.sh' /mnt/sda3/0git/pkgconf/tests/meson.build:2:16: warning The variable 'prefix' in the input file '/mnt/sda3/0git/pkgconf/tests/test_env.sh.in' is not present in the given configuration data 2 | configure_file(input: 'test_env.sh.in', output: 'test_env.sh', configuration: cdata) ^ /mnt/sda3/0git/pkgconf/tests/meson.build:2:16: warning The variable 'exec_prefix' in the input file '/mnt/sda3/0git/pkgconf/tests/test_env.sh.in' is not present in the given configuration data 2 | configure_file(input: 'test_env.sh.in', output: 'test_env.sh', configuration: cdata) ^ /mnt/sda3/0git/pkgconf/tests/meson.build:2:16: warning The variable 'datarootdir' in the input file '/mnt/sda3/0git/pkgconf/tests/test_env.sh.in' is not present in the given configuration data 2 | configure_file(input: 'test_env.sh.in', output: 'test_env.sh', configuration: cdata) ^ configuring '/mnt/sda3/0git/pkgconf/builddir/tests/basic'
Comment by ~wdlkmpx on ~lattis/muon
Yes meson recognizes the AR env variable and overrides the default ar string if your export it. So this just increases meson compatibility
Well meson does require the --cross-file if cross compiling for a different CPU architecture (or a different libc without generating static binaries), apparently it always creates a test binary that needs to run. That's not an issue with muon unless the meson project specifies something like
compiler: native, and then tries to run the binary, that's when muon will die (i.e. muon can't cross compile muon)
Comment by ~wdlkmpx on ~lattis/muon
The fact that AR is hard-coded is indeed a major issue when using something else than the default system compiler. The patch above doesn't seem cause side effects, looks ok to me, but I'm not really sure what I'm doing. The only change I think of is this, to silence a warning .... I also notice that
run_cmd_arr()can be used but does not apply to string typediff --git a/src/compilers.c b/src/compilers.c index a391ce90..4815ab0e 100644 --- a/src/compilers.c +++ b/src/compilers.c @@ -1059,10 +1059,14 @@ enum ar_type { }; static enum ar_type -compiler_detect_ar_type(void) +compiler_detect_ar_type(struct workspace *wk) { + obj ar; + get_option_value(wk, NULL, "env.AR", &ar); + char *ar_cmd[] = { (char*)get_cstr(wk, ar), "--version", NULL }; + struct run_cmd_ctx cmd_ctx = { 0 }; - if (!run_cmd_argv(&cmd_ctx, (char *[]){ "ar", "--version", NULL }, NULL, 0)) { + if (!run_cmd_argv(&cmd_ctx, ar_cmd, NULL, 0)) { run_cmd_ctx_destroy(&cmd_ctx); return ar_posix; }
Comment by ~wdlkmpx on ~lattis/muon
I export all those variables for binutils apps, usually to deal with projects that only support plain Makefiles, I patch Makefiles so that stuff works the way it should
meson doesn't like it when LD and/or CC_LD is not set to some predefined value (gold, lld, bfd?, etc), so I don't export those variables when I use meson, only with muon. but muon doesn't support changing the linker, so it's not problem anyway
So basically LD is the linker binary and CC_LD may be a param for the compiler?, I shouldn't export CC_LD to test this with meson, but I'm pretty sure it works, now it should be documented somewhere that (almost) all binutils binaries can be overridden through environment variables
Comment by ~wdlkmpx on ~lattis/muon
This works for me, simple apps that support mingw natively compile fine. But muon can't install .exe files, because the extension is missing, but this patch that adds support for
ARenv variable works for meThis actually fixes potential issues with linux cross-builds as well, the system AR may be too old/unsuitable for the cross-compiler toolchain, so there's a strong need to override it, like this:
export AR=i686-w64-mingw32-ar,export AR=i686-linux-musl-ardiff --git a/include/compilers.h b/include/compilers.h index c91e9d4c..6d076a34 100644 --- a/include/compilers.h +++ b/include/compilers.h @@ -159,5 +159,5 @@ enum compiler_language coalesce_link_languages(enum compiler_language cur, enum bool compiler_detect(struct workspace *wk, obj *comp, enum compiler_language lang); void compilers_init(void); -const char *ar_arguments(void); +const char *ar_arguments(struct workspace *wk); #endif diff --git a/src/backend/ninja/build_target.c b/src/backend/ninja/build_target.c index d7f7a344..f4eca755 100644 --- a/src/backend/ninja/build_target.c +++ b/src/backend/ninja/build_target.c @@ -116,6 +116,8 @@ write_tgt_sources_iter(struct workspace *wk, void *_ctx, obj val) bool ninja_write_build_tgt(struct workspace *wk, obj tgt_id, struct write_tgt_ctx *wctx) { + obj ar; + const char *ar_str = NULL; struct obj_build_target *tgt = get_obj_build_target(wk, tgt_id); L("writing rules for target '%s'", get_cstr(wk, tgt->build_name)); @@ -227,7 +229,9 @@ ninja_write_build_tgt(struct workspace *wk, obj tgt_id, struct write_tgt_ctx *wc break; case tgt_static_library: linker_type = "static"; - link_args = ar_arguments(); + get_option_value(wk, NULL, "env.AR", &ar); + ar_str = get_cstr(wk,ar); + link_args = ar_arguments(wk); break; default: assert(false); @@ -248,6 +252,10 @@ ninja_write_build_tgt(struct workspace *wk, obj tgt_id, struct write_tgt_ctx *wc fputs(" || ", wctx->out); fputs(get_cstr(wk, ctx.order_deps), wctx->out); } + + if (ar_str) { + fprintf(wctx->out, "\n AR = %s", ar_str); + } fprintf(wctx->out, "\n LINK_ARGS = %s\n", link_args); if (tgt->flags & build_tgt_flag_build_by_default) { diff --git a/src/backend/ninja/rules.c b/src/backend/ninja/rules.c index 53f27109..41972d9f 100644 --- a/src/backend/ninja/rules.c +++ b/src/backend/ninja/rules.c @@ -300,7 +300,7 @@ ninja_write_rules(FILE *out, struct workspace *wk, struct project *main_proj, fprintf(out, "rule static_linker\n" - " command = rm -f $out && ar $LINK_ARGS $out $in\n" + " command = rm -f $out && $AR $LINK_ARGS $out $in\n" " description = linking static $out\n" "\n" "rule CUSTOM_COMMAND\n" diff --git a/src/compilers.c b/src/compilers.c index a391ce90..618d9b1e 100644 --- a/src/compilers.c +++ b/src/compilers.c @@ -1059,10 +1059,13 @@ enum ar_type { }; static enum ar_type -compiler_detect_ar_type(void) +compiler_detect_ar_type(struct workspace *wk) { + obj ar; + get_option_value(wk, NULL, "env.AR", &ar); + struct run_cmd_ctx cmd_ctx = { 0 }; - if (!run_cmd_argv(&cmd_ctx, (char *[]){ "ar", "--version", NULL }, NULL, 0)) { + if (!run_cmd_argv(&cmd_ctx, (char *[]){ get_cstr(wk, ar), "--version", NULL }, NULL, 0)) { run_cmd_ctx_destroy(&cmd_ctx); return ar_posix; } @@ -1078,13 +1081,13 @@ compiler_detect_ar_type(void) } const char * -ar_arguments(void) +ar_arguments(struct workspace *wk) { static enum ar_type ar_type; static bool ar_type_initialized = false; if (!ar_type_initialized) { - ar_type = compiler_detect_ar_type(); + ar_type = compiler_detect_ar_type(wk); ar_type_initialized = true; } diff --git a/src/options.c b/src/options.c index 527c46b2..32eea47f 100644 --- a/src/options.c +++ b/src/options.c @@ -814,12 +814,14 @@ init_global_options(struct workspace *wk) "option('env.CC', type: 'array', value: ['cc'])\n" "option('env.NINJA', type: 'array', value: ['ninja'])\n" + "option('env.AR', type: 'string', value: 'ar')\n" )) { return false; } set_binary_from_env(wk, "CC", "env.CC"); set_binary_from_env(wk, "NINJA", "env.NINJA"); + set_str_opt_from_env(wk, "AR", "env.AR"); set_compile_opt_from_env(wk, "c_args", "CFLAGS", "CPPFLAGS"); set_compile_opt_from_env(wk, "c_link_args", "CFLAGS", "LDFLAGS"); diff --git a/src/script/global_options.meson b/src/script/global_options.meson index 58ab2567..eaab0e9e 100644 --- a/src/script/global_options.meson +++ b/src/script/global_options.meson @@ -148,6 +148,7 @@ option('cpp_winlibs', type: 'array', value: []) # TODO option('env.CC', type: 'array', value: ['cc']) option('env.CXX', type: 'array', value: ['c++']) +option('env.AR', type: 'string', value: 'ar') option('env.OBJC', type: 'array', value: ['cc']) option('env.NINJA', type: 'array', value: ['ninja']) option('env.NASM', type: 'array', value: ['nasm'])
Ticket created by ~wdlkmpx on ~lattis/muon
I have problems cross-compiling for non-linux targets (i.e. mingw)
muon doesn't officially supports cross-compilation.. but as long as CC/CXX/LDFLAGS/CFLAGS/CXXFLAGS are exported with proper values.. cross-compilation succeeds
the meson docs mention env variables to override default compiler and linker (CC CXX CC_LD CXX_LD) https://mesonbuild.com/Reference-tables.html#compiler-and-linker-selection-variables
But there's no way to override the AR command, so I have to use a --cross-file
[18/19] rm -f libpkgconf.a && i686-w64-mingw32-ar csrD libpkgconf.a ... [19/19] i686-w64-mingw32-gcc -o pkgconf.exe ...So AR is definitely not hard-coded, it can be changed... in a meson --cross-file
muon: https://github.com/annacrombie/muon/blob/master/src/backend/ninja/rules.c#L303
[18/19] rm -f libpkgconf.a && ar csrD libpkgconf.a ... [19/19] i686-w64-mingw32-gcc -o pkgconf .... ../i686-w64-mingw32/bin/ld: libpkgconf.a: error adding symbols: archive has no index; run ranlib to add oneWhen dealing with pure Makefiles, the
ARenv variable is usually supportedPerhaps muon should recognize the AR env variable and assign it to the (new) internal ar command or something.. Or maybe recognize something muon-specific:
MUON_AR, as a muon extension
aris just one of several possible binutils apps that are used when building stuff
Comment by ~wdlkmpx on ~lattis/muon
The problem with test_libucontext is that that app is compiled without flags (meson passes da flags), it's the only thing that has not been fixed, don't know what really happens, but perhaps it has to do with with the fact that it's compiled after a .S file.. Not really important since it's like a small disturbance in the force, doesn't make sense why the app doesn't receive the flags
Comment by ~wdlkmpx on ~lattis/muon
using the latest muon git revision, this doesn't work:
# muon -C builddir setup err missing operandmeson 1.0.1
# meson -C builddir setup usage: meson [-h] {setup,configure,dist,install,introspect,init,test,wrap,subprojects,rewrite,compile,devenv,env2mfile,help} ... meson: error: unrecognized arguments: -CThis is an issue I had months ago, extremely confusing how to use meson & muon, but now both work with the same setup command:
# muon setup [options] builddir # meson setup [options] builddirI found that older versions than meson 1.0 make everything harder and confusing. Of course muon should improve add support for
-C DIRafter command, that single change would make the world a happier place