https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249
--- Comment #3 from Liviu Ionescu <ilg at livius dot net> ---
Hi Richard,
Thank you for taking the time to investigate.
Indeed, COLLECT_LTO_WRAPPER is escaped, while COMPILER_PATH is not:
COLLECT_LTO_WRAPPER=c:/users/ilg/desktop/8.2.1\ \ \ \ \
1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe
...
COMPILER_PATH=c:/users/ilg/desktop/8.2.1
1.4-20190207-1853/bin/../libexec/gcc/arm-none-eabi/8.2.1/;c:/users/ilg/desktop/8.2.1
1.4-20190207-1853/bin/../libexec/gcc/;c:/users/ilg/desktop/8.2.1
1.4-20190207-1853/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/
However, COMPILER_PATH is also not escaped in the no-LTO case, which works, so
I guess it is escaped somewhere else, and this is missing in the LTO code.
The only meaningful place where COMPILER_PATH is used is in
gcc.c:driver::maybe_run_linker():
putenv_from_prefixes (&exec_prefixes, "COMPILER_PATH", false);
putenv_from_prefixes (&startfile_prefixes, LIBRARY_PATH_ENV, true);
Right now I see convert_white_space() called only twice:
lto_wrapper_file = find_a_file (&exec_prefixes, "lto-wrapper",
X_OK, false);
and
linker_plugin_file_spec = convert_white_space (temp_spec);
>From what I undestand, the path in 'exec_prefixes' should have been converted
before putenv_from_prefixes() is called.
'exec_prefixes' seems constructed via
add_prefix (&exec_prefixes, arg, NULL,
PREFIX_PRIORITY_B_OPT, 0, 0);
>From here... I'm kind of lost, the logic to manage paths is complex and I can't
estimate the impacts of changes, but I think that this path change mandatory
for Windows should be done in a single place, not everywhere the paths are
finally consumed.
So, we got a bit of understanding, but the ploblem seems to require more
thinking and a careful solution, which I'm not able to provide.
However, if someone can, I'm ready to try it.
