[Bug driver/89249] mingw, paths with spaces, LTO -> collect2.exe: fatal error: CreateProcess: No such file or directory

ilg at livius dot net gcc-bugzilla@gcc.gnu.org
Fri Feb 8 13:01:00 GMT 2019


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.


More information about the Gcc-bugs mailing list