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

2021-09-01 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249

Andrew Pinski  changed:

   What|Removed |Added

 CC||marcoxa at gmail dot com

--- Comment #7 from Andrew Pinski  ---
*** Bug 98175 has been marked as a duplicate of this bug. ***

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

2019-02-08 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249

Richard Biener  changed:

   What|Removed |Added

 Target||mingw
  Component|other   |driver

--- Comment #2 from Richard Biener  ---
I see COLLECT_LTO_WRAPPER with properly escaped spaces but COMPILER_PATH not.
This is build from gcc.c:build_search_list which is simplistic so 'paths'
and 'prefix' have to be escaped properly already.

The paths are populated from find_a_file.

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

2019-02-08 Thread ilg at livius dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249

--- Comment #3 from Liviu Ionescu  ---
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.

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

2019-02-13 Thread ilg at livius dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249

--- Comment #4 from Liviu Ionescu  ---
I added a printf() in pex_win32_exec_child() to see why the lto invocation
fails, and here is the result:


> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
> 1.4-20190213-0923/bin/../libexec/gcc/arm-none-eabi/8.2.1/collect2.exe') 
> <
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe')
>  <
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>  <
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>  <
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>  <
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>  <
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>  <
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1 
> 1.4-20190213-0923/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/nm.exe')
>  <
> pex_win32_exec_child (executable='c:/users/ilg/desktop/8.2.1\ \ \ \ \ 
> 1.4-20190213-0923/bin/../libexec/gcc/arm-none-eabi/8.2.1/lto-wrapper.exe')
>  <
collect2.exe: fatal error: CreateProcess: No such file or directory
compilation terminated.

C:\Users\ilg\tmp\lto>



it looks like the win32 api is not happy with the escaped spaces in the
lto-wrapper path.


I conditionally removed the white space conversion in gcc.c (around line 7741)
and the problem was fixed:


#if defined (__MINGW32__)
  // Win32 fails to CreateProcess if spaces are escaped.
  lto_wrapper_spec = lto_wrapper_file;
#else
  lto_wrapper_file = convert_white_space (lto_wrapper_file);
#endif


I did the same for the second reference to convert_white_space(), while
processing the linker_plugin_file_spec, but I do not have a clear reason why
this is needed, since aparently the name of the temporary files used for the
specs file is generate by win32 in the 8.3 format, and has no spaces.


I tried to remove the conversion entirely, but then ld fails to load the
plugin:


/home/ilg/Desktop/8.2.1   
1.4-20190213-1020/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld:
/home/ilg/Desktop/8.2.1: error loading plugin: /home/ilg/Desktop/8.2.1: cannot
open shared object file: No such file or directory
collect2: error: ld returned 1 exit status
ilg@ilg-ud18lts64-gme:~/tmp/lto$ 



I'll apply a patch to build my distribution, but I think a more elaborate
solution is needed.


Although not related to this issue, another curious thing was the sequence of 6
calls to nm shown by the trace. Are they expected?

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

2019-02-13 Thread ilg at livius dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249

--- Comment #5 from Liviu Ionescu  ---
The patch is wrong, it should read:

#if defined (__MINGW32__)
  // Win32 fails to CreateProcess if spaces are escaped.
#else
  lto_wrapper_file = convert_white_space (lto_wrapper_file);
#endif

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

2019-05-09 Thread ilg at livius dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89249

--- Comment #6 from Liviu Ionescu  ---
I upgraded my mingw to 5.0.4 and I can no longer reproduce the problem, so I
suggest we close this ticket for now and reopen if necessary.