Use response files with all the toolchains #151
Conversation
|
The support for GNAT has been added for AdaCore, butt I think we've actually stopped using this codepath entirely. Unfortunately I've left AdaCore recently, so you will need to double-check with e.g. @kanigsson. In any case, GNAT is based on GCC, and is only lagging a few versions behind. Typically, the latest versions are GCC-13 based. So I would suggest using response files in all cases. |
Thank you for your suggestion! I'll update the PR |
Response files were added to gcc 4.2.0 [1], but Cygwin was stuck on gcc 3.4.4 for ages until mingw-w64 was introduced at gcc 4.5 (Cygwin's gcc itself still lagged for a while) cf. [2]. (Based on inputs from @dra27). So, in 2008 [3], it was correct to avoid using response files with CYGWIN & MINGW. Later, support was added for the GNAT toolchain based on the MINGW toolchain, also avoiding the use of response files. But, now all the platforms could benefit from using response files. This commit enables the use of response files for all toolchains, including GNAT since the GNAT compiler is based on gcc [4]. The UTF-16 conversion of paths seems to have been primarily implemented for MSVC[5] and causes issues with MINGW64. The linker fails with a "file not found" error with a weird 2 character file path, which seems like an encoding issue when reading the Byte Order Mark written during the conversion. This commit turns off the UTF-16 conversion when not using the MSVC or LIGHTLD toolchains. [1] - gcc-mirror/gcc@9d53053 [2] - http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2010/09/14/020013/index.html [3] - ocaml@fb84938 [4] - ocaml#151 (comment) [5] - ocaml#36
punchagan
force-pushed
the
mingw-response-file
branch
from
510fdb1 to
124facc
Compare
punchagan
changed the title
Updated the PR to use toolchains for GNAT too! |
|
Sorry I missed this mention by @yakobowski. GNAT behaves like GCC here. |
Response files were added to gcc 4.2.0 [1], but Cygwin was stuck on gcc 3.4.4 for ages until mingw-w64 was introduced at gcc 4.5 (Cygwin's gcc itself still lagged for a while) cf. [2]. (Based on inputs from @dra27). So, in 2008 [3], it was correct to avoid using response files with CYGWIN & MINGW. Later, support was added for the GNAT toolchain based on the MINGW toolchain, also avoiding the use of response files. But, now all the platforms could benefit from using response files. This commit enables the use of response files for all toolchains, including GNAT since the GNAT compiler is based on gcc [4]. The UTF-16 conversion of paths seems to have been primarily implemented for MSVC[5] and causes issues with MINGW64. The linker fails with a "file not found" error with a weird 2 character file path, which seems like an encoding issue when reading the Byte Order Mark written during the conversion. This commit turns off the UTF-16 conversion when not using the MSVC or LIGHTLD toolchains. [1] - gcc-mirror/gcc@9d53053 [2] - http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2010/09/14/020013/index.html [3] - ocaml@fb84938 [4] - ocaml#151 (comment) [5] - ocaml#36
punchagan
force-pushed
the
mingw-response-file
branch
from
124facc to
4b71b44
Compare
|
Hello! I thought it was worth checking in here to see if we may be OK merging this, or if there additional validation we may do to build the needed confidence. |
Response files were added to gcc 4.2.0 [1], but Cygwin was stuck on gcc
3.4.4 for ages until mingw-w64 was introduced at gcc 4.5 (Cygwin's gcc
itself still lagged for a while) cf. [2]. (Based on inputs from @dra27).
So, in 2008 [3], it was correct to avoid using response files with
CYGWIN & MINGW. Later, support was added for the GNAT toolchain based on
the MINGW toolchain, also avoiding the use of response files. But, now
all the platforms could benefit from using response files. This commit
enables the use of response files for all toolchains, including GNAT
since the GNAT compiler is based on gcc [4].
The UTF-16 conversion of paths seems to have been primarily implemented
for MSVC[5] and causes issues with MINGW64. The linker fails with a
"file not found" error with a weird 2 character file path, which seems
like an encoding issue when reading the Byte Order Mark written during
the conversion. This commit turns off the UTF-16 conversion when not
using the MSVC or LIGHTLD toolchains.
[1] - gcc-mirror/gcc@9d53053
[2] - http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2010/09/14/020013/index.html
[3] -
fb84938
[4] - #151 (comment)
[5] - #36