public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug driver/108350] New: Windows: invoking gcc via symlink does not work
@ 2023-01-10 9:47 gnu.org at billz dot fastmail.fm
2023-01-10 10:40 ` [Bug driver/108350] " i.nixman at autistici dot org
` (37 more replies)
0 siblings, 38 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-10 9:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
Bug ID: 108350
Summary: Windows: invoking gcc via symlink does not work
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu.org at billz dot fastmail.fm
Target Milestone: ---
PROBLEM
On Windows if I invoke gcc via a symlink, then it is unable to work. This
appears to happen because it computes the wrong prefix.
The steps to reproduce are:
- Install mingw gcc from https://github.com/niXman/mingw-builds
- Open a powershell prompt.
- Execute: `cmd /c mklink gcc.exe <GCC-INSTALL-PATH>\gcc.exe`. This command
creates a symlink on Windows, which requires Administrator or Developer mode to
be enabled.
- Execute: `ni a.c`. This command creates an empty file `a.c`.
- Execute: `.\gcc.exe a.c`. This command fails with "fatal error: cannot
execute 'cc1': CreateProcess: No such file or directory".
- Execute: `.\gcc.exe -print-search-dirs`. This command prints directories
relative to the location of the symlink, rather than the gcc installation path.
The expected behavior is for `gcc` to work regardless of whether it is invoked
via a symlink or not, because I did not supply the `-no-canonical-prefixes`
option.
This problem was originally reported against the mingw-builds repository, but
investigation showed that the problem is likely with gcc.
INVESTIGATION
Investigation showed that gcc prefixes are handled in `process_command`
(gcc/gcc.cc). When the `-no-canonical-prefixes` option is not supplied prefix
resolution happens in `make_relative_prefix` (libiberty/make-relative-prefix.c)
which calls `lrealpath` (libiberty/lrealpath.c).
On Windows `lrealpath` calls `GetFullPathName` which unfortunately does *not*
do symlink resolution.
FIX
The most straightforward fix is to change `lrealpath` to use
`GetFinalPathNameByHandle` instead of `GetFullPathName`.
For the original issue report and an alternative view of this issue please see
here: https://github.com/niXman/mingw-builds/issues/633
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
@ 2023-01-10 10:40 ` i.nixman at autistici dot org
2023-01-10 12:27 ` gnu.org at billz dot fastmail.fm
` (36 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-10 10:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #1 from niXman <i.nixman at autistici dot org> ---
> FIX
>
> The most straightforward fix is to change `lrealpath` to use
> `GetFinalPathNameByHandle` instead of `GetFullPathName`.
thanks for the investigation!
will do it now.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
2023-01-10 10:40 ` [Bug driver/108350] " i.nixman at autistici dot org
@ 2023-01-10 12:27 ` gnu.org at billz dot fastmail.fm
2023-01-10 12:29 ` i.nixman at autistici dot org
` (35 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-10 12:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #2 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #1)
> > The most straightforward fix is to change `lrealpath` to use
> > `GetFinalPathNameByHandle` instead of `GetFullPathName`.
>
> thanks for the investigation!
> will do it now.
Thank you!
FYI `GetFinalPathNameByHandle` is known to fail on drives that are created via
`DefineDosDevice` (e.g. via the SUBST command). So I recommend using
`GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
fails.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
2023-01-10 10:40 ` [Bug driver/108350] " i.nixman at autistici dot org
2023-01-10 12:27 ` gnu.org at billz dot fastmail.fm
@ 2023-01-10 12:29 ` i.nixman at autistici dot org
2023-01-10 12:37 ` i.nixman at autistici dot org
` (34 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-10 12:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #3 from niXman <i.nixman at autistici dot org> ---
(In reply to Bill Zissimopoulos from comment #2)
> (In reply to niXman from comment #1)
> > > The most straightforward fix is to change `lrealpath` to use
> > > `GetFinalPathNameByHandle` instead of `GetFullPathName`.
> >
> > thanks for the investigation!
> > will do it now.
>
> Thank you!
>
> FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> fails.
got it, thanks!
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (2 preceding siblings ...)
2023-01-10 12:29 ` i.nixman at autistici dot org
@ 2023-01-10 12:37 ` i.nixman at autistici dot org
2023-01-10 13:20 ` gnu.org at billz dot fastmail.fm
` (33 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-10 12:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #4 from niXman <i.nixman at autistici dot org> ---
> FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> fails.
could you give me a hint, what should I use for `dwFlags` param for
`GetFinalPathNameByHandle()` ? (because for me all the options are
incomprehensible)
because according to your github profile it looks like you are Windows
developer :)
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea#parameters
thanks!
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (3 preceding siblings ...)
2023-01-10 12:37 ` i.nixman at autistici dot org
@ 2023-01-10 13:20 ` gnu.org at billz dot fastmail.fm
2023-01-10 13:22 ` i.nixman at autistici dot org
` (32 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-10 13:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #5 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #4)
> > FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> > via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> > `GetFullPathName` as a fallback if you find that `GetFinalPathNameByHandle`
> > fails.
>
> could you give me a hint, what should I use for `dwFlags` param for
> `GetFinalPathNameByHandle()` ? (because for me all the options are
> incomprehensible)
I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (4 preceding siblings ...)
2023-01-10 13:20 ` gnu.org at billz dot fastmail.fm
@ 2023-01-10 13:22 ` i.nixman at autistici dot org
2023-01-10 13:25 ` gnu.org at billz dot fastmail.fm
` (31 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-10 13:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #6 from niXman <i.nixman at autistici dot org> ---
> I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.
together? OR'ed?
or should I try for the first, and for the second one? or...?
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (5 preceding siblings ...)
2023-01-10 13:22 ` i.nixman at autistici dot org
@ 2023-01-10 13:25 ` gnu.org at billz dot fastmail.fm
2023-01-10 13:49 ` i.nixman at autistici dot org
` (30 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-10 13:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #7 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #6)
> > I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.
>
> together? OR'ed?
>
> or should I try for the first, and for the second one? or...?
Yes, or them together: `FILE_NAME_NORMALIZED | VOLUME_NAME_DOS`.
- `FILE_NAME_NORMALIZED` is needed to actually perform the symbolic link
resolution.
- `VOLUME_NAME_DOS` is needed to translate the internal NT device name to the
familiar Win32 drives (X:). This may fail with `ERROR_UNRECOGNIZED_VOLUME`
which is why I recommended to use GetFullPathName as a fallback mechanism.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (6 preceding siblings ...)
2023-01-10 13:25 ` gnu.org at billz dot fastmail.fm
@ 2023-01-10 13:49 ` i.nixman at autistici dot org
2023-01-10 14:54 ` gnu.org at billz dot fastmail.fm
` (29 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-10 13:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #8 from niXman <i.nixman at autistici dot org> ---
> Yes, or them together: `FILE_NAME_NORMALIZED | VOLUME_NAME_DOS`.
>
> - `FILE_NAME_NORMALIZED` is needed to actually perform the symbolic link
> resolution.
>
> - `VOLUME_NAME_DOS` is needed to translate the internal NT device name to
> the familiar Win32 drives (X:). This may fail with
> `ERROR_UNRECOGNIZED_VOLUME` which is why I recommended to use
> GetFullPathName as a fallback mechanism.
done, thanks!
in building process... will report.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (7 preceding siblings ...)
2023-01-10 13:49 ` i.nixman at autistici dot org
@ 2023-01-10 14:54 ` gnu.org at billz dot fastmail.fm
2023-01-10 18:57 ` i.nixman at autistici dot org
` (28 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-10 14:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #9 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
Thank you.
Let me know if you need any help from me.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (8 preceding siblings ...)
2023-01-10 14:54 ` gnu.org at billz dot fastmail.fm
@ 2023-01-10 18:57 ` i.nixman at autistici dot org
2023-01-10 20:52 ` i.nixman at autistici dot org
` (27 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-10 18:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #10 from niXman <i.nixman at autistici dot org> ---
it is strange, but for some reason I can't build master nor 12.2.0 because of
error:
```
{
/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/nm
-pg _chkstk_s.o _chkstk_ms_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o
_ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o
_trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o
_subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o
_umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o gthr-win32_s.o cpuinfo_s.o
sfp-exceptions_s.o _divhc3_s.o _mulhc3_s.o addtf3_s.o divtf3_s.o eqtf2_s.o
getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o
floatuntitf_s.o extendhfsf2_s.o extendhfdf2_s.o extendhftf2_s.o extendhfxf2_s.o
extendsfdf2_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfhf2_s.o
truncxfhf2_s.o truncdfhf2_s.o truncsfhf2_s.o trunctfsf2_s.o truncdfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o fixhfti_s.o fixunshfti_s.o floattihf_s.o
floatuntihf_s.o eqhf2_s.o enable-execute-stack_s.o unwind-seh_s.o
unwind-sjlj_s.o unwind-c_s.o emutls_s.o emutls_s.o; echo %%; \
cat libgcc.map.in; \
} | gawk -f ../../../../../src/gcc-12.2.0/libgcc/mkmap-flat.awk -v
pe_dll=libgcc_s_seh-1.dll > tmp-libgcc.map
mv tmp-libgcc.map libgcc.map
# @multilib_flags@ is still needed because this may use
#
/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/xgcc
-B/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include -fno-checking and -O2
-I../../../../../src/gcc-12.2.0/libgcc/../winsup/w32api/include -g -O2 -pipe
-fno-ident
-I/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/mingw64/opt/include
-I/c/mingw-builds/prerequisites/x86_64-zlib-static/include
-I/c/mingw-builds/prerequisites/x86_64-w64-mingw32-static/include -DIN_GCC
-fPIC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../../../../../src/gcc-12.2.0/libgcc/../mkinstalldirs .
cp -pR -f libgcc.map libgcc.map.def && if [ ! -d ./shlib ]; then mkdir ./shlib;
else true; fi &&
/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/xgcc
-B/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include -fno-checking -O2
-I../../../../../src/gcc-12.2.0/libgcc/../winsup/w32api/include -g -O2 -pipe
-fno-ident
-I/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/mingw64/opt/include
-I/c/mingw-builds/prerequisites/x86_64-zlib-static/include
-I/c/mingw-builds/prerequisites/x86_64-w64-mingw32-static/include -DIN_GCC
-fPIC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared
-nodefaultlibs libgcc.map.def -Wl,--out-implib,./shlib/libgcc_s.a.tmp -o
./shlib/libgcc_s_seh-1.dll.tmp -g -O2 -pipe -fno-ident
-I/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/mingw64/opt/include
-I/c/mingw-builds/prerequisites/x86_64-zlib-static/include
-I/c/mingw-builds/prerequisites/x86_64-w64-mingw32-static/include -B./
_chkstk_s.o _chkstk_ms_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o
_ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o
__main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o
_subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o
_ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o
_umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o gthr-win32_s.o cpuinfo_s.o
sfp-exceptions_s.o _divhc3_s.o _mulhc3_s.o addtf3_s.o divtf3_s.o eqtf2_s.o
getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o
floatuntitf_s.o extendhfsf2_s.o extendhfdf2_s.o extendhftf2_s.o extendhfxf2_s.o
extendsfdf2_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfhf2_s.o
truncxfhf2_s.o truncdfhf2_s.o truncsfhf2_s.o trunctfsf2_s.o truncdfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o fixhfti_s.o fixunshfti_s.o floattihf_s.o
floatuntihf_s.o eqhf2_s.o enable-execute-stack_s.o unwind-seh_s.o
unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lmingwthrd -lmingw32
-lmingwex -lmoldname -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 && if [
-f ./shlib/libgcc_s_seh-1.dll ]; then mv -f ./shlib/libgcc_s_seh-1.dll
./shlib/libgcc_s_seh-1.dll.backup; else true; fi && mv
./shlib/libgcc_s_seh-1.dll.tmp ./shlib/libgcc_s_seh-1.dll && mv
./shlib/libgcc_s.a.tmp ./shlib/libgcc_s.a
# Now that we have built all the objects, we need to copy
# them back to the GCC directory. Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
/bin/make install-leaf DESTDIR=../.././gcc \
slibdir= libsubdir= MULTIOSDIR=.
make[4]: Entering directory
'/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/x86_64-w64-mingw32/libgcc'
__gcc_bcmp.dep:1: *** multiple target patterns. Stop.
```
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (9 preceding siblings ...)
2023-01-10 18:57 ` i.nixman at autistici dot org
@ 2023-01-10 20:52 ` i.nixman at autistici dot org
2023-01-10 21:31 ` gnu.org at billz dot fastmail.fm
` (26 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-10 20:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #11 from niXman <i.nixman at autistici dot org> ---
even with a downgraded host toolchain to that which uses mingw-w64 rt-v9 I get
the same error...
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (10 preceding siblings ...)
2023-01-10 20:52 ` i.nixman at autistici dot org
@ 2023-01-10 21:31 ` gnu.org at billz dot fastmail.fm
2023-01-12 19:24 ` i.nixman at autistici dot org
` (25 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-10 21:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #12 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #10)
> it is strange, but for some reason I can't build master nor 12.2.0 because
> of error:
Unfortunately I am not really familiar with the gcc build process to be of much
help here.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (11 preceding siblings ...)
2023-01-10 21:31 ` gnu.org at billz dot fastmail.fm
@ 2023-01-12 19:24 ` i.nixman at autistici dot org
2023-01-13 10:28 ` gnu.org at billz dot fastmail.fm
` (24 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-12 19:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #13 from niXman <i.nixman at autistici dot org> ---
I figured out the building problem.
it seems to work as it should for symlink, but it doesn't work for hardlink.
will dive into docs...
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (12 preceding siblings ...)
2023-01-12 19:24 ` i.nixman at autistici dot org
@ 2023-01-13 10:28 ` gnu.org at billz dot fastmail.fm
2023-01-13 10:32 ` i.nixman at autistici dot org
` (23 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-13 10:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #14 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #13)
> I figured out the building problem.
>
> it seems to work as it should for symlink, but it doesn't work for hardlink.
This is good news.
Unless I misunderstand what you mean I think working for symlink, but not
working for hardlink is expected behavior. There is no way to resolve a
hardlink to a "real" path, all hardlinked paths are "real".
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (13 preceding siblings ...)
2023-01-13 10:28 ` gnu.org at billz dot fastmail.fm
@ 2023-01-13 10:32 ` i.nixman at autistici dot org
2023-01-13 10:34 ` i.nixman at autistici dot org
` (22 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-13 10:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #15 from niXman <i.nixman at autistici dot org> ---
> There is no way to resolve a hardlink to a "real" path, all hardlinked paths are "real".
according to this link:
https://stackoverflow.com/questions/10260676/programmatically-finding-the-target-of-a-windows-hard-link
it seems hardlinks should be resolved too. or I'm wrong?
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (14 preceding siblings ...)
2023-01-13 10:32 ` i.nixman at autistici dot org
@ 2023-01-13 10:34 ` i.nixman at autistici dot org
2023-01-13 10:43 ` gnu.org at billz dot fastmail.fm
` (21 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-13 10:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #16 from niXman <i.nixman at autistici dot org> ---
Created attachment 54264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54264&action=edit
patch
the patch for `lrealpath()` for win32.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (15 preceding siblings ...)
2023-01-13 10:34 ` i.nixman at autistici dot org
@ 2023-01-13 10:43 ` gnu.org at billz dot fastmail.fm
2023-01-13 10:43 ` gnu.org at billz dot fastmail.fm
` (20 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-13 10:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #17 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #15)
> > There is no way to resolve a hardlink to a "real" path, all hardlinked paths are "real".
>
> according to this link:
> https://stackoverflow.com/questions/10260676/programmatically-finding-the-
> target-of-a-windows-hard-link
>
> it seems hardlinks should be resolved too. or I'm wrong?
It is possible on Windows to enumerate all hard links using FindFirstFileNameW
/ FindNextFileNameW. But conceptually at least all hard links are equal to each
other, even if on some file systems a particular hard link is "more equal" than
the others. So IMO hard link resolution makes little sense.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (16 preceding siblings ...)
2023-01-13 10:43 ` gnu.org at billz dot fastmail.fm
@ 2023-01-13 10:43 ` gnu.org at billz dot fastmail.fm
2023-01-13 11:04 ` gnu.org at billz dot fastmail.fm
` (19 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-13 10:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #18 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #16)
> Created attachment 54264 [details]
> patch
>
> the patch for `lrealpath()` for win32.
Thanks for patch. Looking at it now.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (17 preceding siblings ...)
2023-01-13 10:43 ` gnu.org at billz dot fastmail.fm
@ 2023-01-13 11:04 ` gnu.org at billz dot fastmail.fm
2023-01-13 11:19 ` gnu.org at billz dot fastmail.fm
` (18 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-13 11:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #19 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
Comment on attachment 54264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54264
patch
Many thanks for the patch. Please consider the following:
LINES 144-152:
I would change the CreateFile call to look like:
HANDLE fh = CreateFile (
filename
,FILE_READ_ATTRIBUTES
,FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
,NULL
,OPEN_EXISTING
,FILE_FLAG_BACKUP_SEMANTICS
,NULL
);
- The FILE_READ_ATTRIBUTES is the only permission required here. (In fact 0
will work as well because CreateFile always adds FILE_READ_ATTRIBUTES.) There
is no need to ask for extra permissions that the process may not have.
- The FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE is something I do
religiously. Although the use of FILE_SHARE_READ should be sufficient in your
case according to documentation, I have found that there are some corner cases
where the use of FILE_SHARE_* flags is not consistent with documentation. To
avoid such cases I use the combo of the flags above.
- The FILE_FLAG_BACKUP_SEMANTICS is needed if lrealpath is used on directories.
LINE 152:
I would fall back to the GetFullPathName method rather than using strdup here.
LINE 192:
There are actually two cases to consider regarding the \\?\ prefix:
- Case \\?\X:\Path\To\File: you should make the conversion \\?\X:\Path\To\File
-> X:\Path\To\File (as you are already doing).
- Case \\?\UNC\Server\Share\Path\To\File: you should make the conversion
\\?\UNC\Server\Share\Path\To\File -> \\Server\Share\Path\To\File
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (18 preceding siblings ...)
2023-01-13 11:04 ` gnu.org at billz dot fastmail.fm
@ 2023-01-13 11:19 ` gnu.org at billz dot fastmail.fm
2023-01-16 8:51 ` i.nixman at autistici dot org
` (17 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-13 11:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #20 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
Regarding LINE 192:
I would add that if somehow the path returned by GetFinalPathNameByHandle does
not conform to the \\?\X: or \\?\UNC\ pattern I would fall back to
GetFullPathName.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (19 preceding siblings ...)
2023-01-13 11:19 ` gnu.org at billz dot fastmail.fm
@ 2023-01-16 8:51 ` i.nixman at autistici dot org
2023-01-16 13:42 ` gnu.org at billz dot fastmail.fm
` (16 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-16 8:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #21 from niXman <i.nixman at autistici dot org> ---
another strange problem is that `CreateFile()` is able to open the special file
`nul` for reading, but `GetFinalPathNameByHandle()` cannot get the full name of
this file and returns 0 and setting `last error` to `ERROR_INVALID_PARAMETER`.
and so you don't get bored I'll add: `GetFullPathName()` can get the full name
of such a file.
(how could this happen? %) )
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (20 preceding siblings ...)
2023-01-16 8:51 ` i.nixman at autistici dot org
@ 2023-01-16 13:42 ` gnu.org at billz dot fastmail.fm
2023-01-16 13:52 ` i.nixman at autistici dot org
` (15 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-16 13:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #22 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #21)
> another strange problem is that `CreateFile()` is able to open the special
> file `nul` for reading, but `GetFinalPathNameByHandle()` cannot get the full
> name of this file and returns 0 and setting `last error` to
> `ERROR_INVALID_PARAMETER`.
>
> and so you don't get bored I'll add: `GetFullPathName()` can get the full
> name of such a file.
>
> (how could this happen? %) )
Yes :)
GetFinalPathNameByHandle internally performs a special request that only file
system drivers respond to (IRP_MJ_QUERY_INFORMATION /
FileNormalizedNameInformation).
So a path like X:\Path\To\File will be resolved to an internal path like:
\Device\<XVOLDEVICE>\Path\To\File
Now \Device\<XVOLDEVICE> is a file system driver (or points to one via an
elaborate mechanism, but let's not complicate matters further) and knows how to
respond to FileNormalizedNameInformation queries.
OTOH a path like nul will be resolved to an internal path like:
\Device\Null
This is a simple device and not a file system driver and does not know how to
respond to FileNormalizedNameInformation queries.
So GetFinalPathNameByHandle works on the first, but not the second.
As for GetFullPathName: I think it works by doing simple string manipulations
on the path (i.e. no attempts to open the file and query its path, etc.)
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (21 preceding siblings ...)
2023-01-16 13:42 ` gnu.org at billz dot fastmail.fm
@ 2023-01-16 13:52 ` i.nixman at autistici dot org
2023-01-16 14:22 ` i.nixman at autistici dot org
` (14 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-16 13:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #23 from niXman <i.nixman at autistici dot org> ---
Created attachment 54280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54280&action=edit
patch
looks like I have finished!
boostrapped successfully as x86_64-mingw-w64.
@Bill Zissimopoulos, @Jonathan Wakely
could you please review the patch?
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (22 preceding siblings ...)
2023-01-16 13:52 ` i.nixman at autistici dot org
@ 2023-01-16 14:22 ` i.nixman at autistici dot org
2023-01-16 17:07 ` i.nixman at autistici dot org
` (13 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-16 14:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #24 from niXman <i.nixman at autistici dot org> ---
BTW, I have no ideas how can I test the patch for UNC ('\\?\UNC' prefixed) ...
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (23 preceding siblings ...)
2023-01-16 14:22 ` i.nixman at autistici dot org
@ 2023-01-16 17:07 ` i.nixman at autistici dot org
2023-01-16 17:27 ` gnu.org at billz dot fastmail.fm
` (12 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-16 17:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #25 from niXman <i.nixman at autistici dot org> ---
updated patch there:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (24 preceding siblings ...)
2023-01-16 17:07 ` i.nixman at autistici dot org
@ 2023-01-16 17:27 ` gnu.org at billz dot fastmail.fm
2023-01-16 17:30 ` i.nixman at autistici dot org
` (11 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-16 17:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #26 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #25)
> updated patch there:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html
A couple of things:
1. If the GetFinalPathNameByHandle method fails, I would always fall back to
the GetFullPathName method (which has fewer failure modes).
GetFinalPathNameByHandle can fail for many reasons: for example, if the drive
X: is a local drive created by SUBST/DefineDosDevice or for special files like
NUL (as you have discovered).
2. I would not do anything particular for special files like NUL. See my above
comment: if GetFinalPathNameByHandle fails fall back to GetFullPathName.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (25 preceding siblings ...)
2023-01-16 17:27 ` gnu.org at billz dot fastmail.fm
@ 2023-01-16 17:30 ` i.nixman at autistici dot org
2023-01-16 18:08 ` i.nixman at autistici dot org
` (10 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-16 17:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #27 from niXman <i.nixman at autistici dot org> ---
ah, got it.
thanks!
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (26 preceding siblings ...)
2023-01-16 17:30 ` i.nixman at autistici dot org
@ 2023-01-16 18:08 ` i.nixman at autistici dot org
2023-01-16 19:31 ` i.nixman at autistici dot org
` (9 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-16 18:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #28 from niXman <i.nixman at autistici dot org> ---
in rebuilding stage...
one more issue: when the symlink called `gcc.exe` and I exec it as `gcc.exe
a.c` - all works as it should, but when I exec it as `gcc a.c` - I get the same
result as before - `fatal error: cannot execute 'cc1': CreateProcess: No such
file or directory`
which way this is usually resolved?
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (27 preceding siblings ...)
2023-01-16 18:08 ` i.nixman at autistici dot org
@ 2023-01-16 19:31 ` i.nixman at autistici dot org
2023-01-18 19:58 ` gnu.org at billz dot fastmail.fm
` (8 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-16 19:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #29 from niXman <i.nixman at autistici dot org> ---
Created attachment 54285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54285&action=edit
patch
another version of the patch.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (28 preceding siblings ...)
2023-01-16 19:31 ` i.nixman at autistici dot org
@ 2023-01-18 19:58 ` gnu.org at billz dot fastmail.fm
2023-01-18 20:08 ` gnu.org at billz dot fastmail.fm
` (7 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-18 19:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #30 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #29)
> Created attachment 54285 [details]
> patch
>
> another version of the patch.
Sorry for the delay. Will look at it now.
(In reply to niXman from comment #28)
> one more issue: when the symlink called `gcc.exe` and I exec it as `gcc.exe
> a.c` - all works as it should, but when I exec it as `gcc a.c` - I get the
> same result as before - `fatal error: cannot execute 'cc1': CreateProcess:
> No such file or directory`
>
> which way this is usually resolved?
Not sure about this one. Are you sure your gcc invocation resulted in finding
your test symlink? In Windows you can do `where.exe gcc` as an equivalent of
`which gcc` on UNIX.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (29 preceding siblings ...)
2023-01-18 19:58 ` gnu.org at billz dot fastmail.fm
@ 2023-01-18 20:08 ` gnu.org at billz dot fastmail.fm
2023-01-18 20:24 ` i.nixman at autistici dot org
` (6 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-18 20:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #31 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #29)
> Created attachment 54285 [details]
> patch
>
> another version of the patch.
Thanks. Your Windows related changes look good to me.
FYI, I am unsure about the need to change all backslashes to slashes and wonder
if this is a backwards incompatible change for users of lrealpath. But I am no
expert in the gcc codebase, so I will let others chime in here.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (30 preceding siblings ...)
2023-01-18 20:08 ` gnu.org at billz dot fastmail.fm
@ 2023-01-18 20:24 ` i.nixman at autistici dot org
2023-01-23 11:44 ` gnu.org at billz dot fastmail.fm
` (5 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-18 20:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #32 from niXman <i.nixman at autistici dot org> ---
> Thanks. Your Windows related changes look good to me.
great, thanks!
> FYI, I am unsure about the need to change all backslashes to slashes and
> wonder if this is a backwards incompatible change for users of lrealpath.
> But I am no expert in the gcc codebase, so I will let others chime in here.
the patch that does nothing but replace slashes in paths, I (and not only me)
have been using for ten years - no one complained =)
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (31 preceding siblings ...)
2023-01-18 20:24 ` i.nixman at autistici dot org
@ 2023-01-23 11:44 ` gnu.org at billz dot fastmail.fm
2023-01-23 11:50 ` i.nixman at autistici dot org
` (4 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-23 11:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #33 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
Now that we have a potential patch what are the steps to get it included into
the gcc codebase?
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (32 preceding siblings ...)
2023-01-23 11:44 ` gnu.org at billz dot fastmail.fm
@ 2023-01-23 11:50 ` i.nixman at autistici dot org
2023-01-23 11:51 ` i.nixman at autistici dot org
` (3 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-23 11:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #34 from niXman <i.nixman at autistici dot org> ---
(In reply to Bill Zissimopoulos from comment #33)
> Now that we have a potential patch what are the steps to get it included
> into the gcc codebase?
great question!
I think the best option is to give me rights to merge =)
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (33 preceding siblings ...)
2023-01-23 11:50 ` i.nixman at autistici dot org
@ 2023-01-23 11:51 ` i.nixman at autistici dot org
2023-01-24 0:02 ` gnu.org at billz dot fastmail.fm
` (2 subsequent siblings)
37 siblings, 0 replies; 39+ messages in thread
From: i.nixman at autistici dot org @ 2023-01-23 11:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #35 from niXman <i.nixman at autistici dot org> ---
and the rights to edit my comments too =)
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (34 preceding siblings ...)
2023-01-23 11:51 ` i.nixman at autistici dot org
@ 2023-01-24 0:02 ` gnu.org at billz dot fastmail.fm
2023-02-11 8:36 ` 10walls at gmail dot com
2023-02-11 8:51 ` gerald at pfeifer dot com
37 siblings, 0 replies; 39+ messages in thread
From: gnu.org at billz dot fastmail.fm @ 2023-01-24 0:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #36 from Bill Zissimopoulos <gnu.org at billz dot fastmail.fm> ---
(In reply to niXman from comment #34)
> (In reply to Bill Zissimopoulos from comment #33)
> > Now that we have a potential patch what are the steps to get it included
> > into the gcc codebase?
>
> great question!
> I think the best option is to give me rights to merge =)
My apologies but I am new to bugzilla and I do not know what that means.
I am looking aroung the bug report user interface and I do not see any obvious
way to give you "rights to merge".
(In reply to niXman from comment #35)
> and the rights to edit my comments too =)
FYI I do not see any obvious way to edit my comments either :)
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (35 preceding siblings ...)
2023-01-24 0:02 ` gnu.org at billz dot fastmail.fm
@ 2023-02-11 8:36 ` 10walls at gmail dot com
2023-02-11 8:51 ` gerald at pfeifer dot com
37 siblings, 0 replies; 39+ messages in thread
From: 10walls at gmail dot com @ 2023-02-11 8:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
jon_y <10walls at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |10walls at gmail dot com
--- Comment #37 from jon_y <10walls at gmail dot com> ---
Nixman's patch has been committed to master branch as
e2bb55ec3b70cf45088bb73ba9ca990129328d60.
^ permalink raw reply [flat|nested] 39+ messages in thread
* [Bug driver/108350] Windows: invoking gcc via symlink does not work
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
` (36 preceding siblings ...)
2023-02-11 8:36 ` 10walls at gmail dot com
@ 2023-02-11 8:51 ` gerald at pfeifer dot com
37 siblings, 0 replies; 39+ messages in thread
From: gerald at pfeifer dot com @ 2023-02-11 8:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
Gerald Pfeifer <gerald at pfeifer dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
CC| |gerald at pfeifer dot com
--- Comment #38 from Gerald Pfeifer <gerald at pfeifer dot com> ---
Marking this as RESOLVED FIXED based on the previous comments and
affirmative reports on gcc-patches@.
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2023-02-11 8:51 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-10 9:47 [Bug driver/108350] New: Windows: invoking gcc via symlink does not work gnu.org at billz dot fastmail.fm
2023-01-10 10:40 ` [Bug driver/108350] " i.nixman at autistici dot org
2023-01-10 12:27 ` gnu.org at billz dot fastmail.fm
2023-01-10 12:29 ` i.nixman at autistici dot org
2023-01-10 12:37 ` i.nixman at autistici dot org
2023-01-10 13:20 ` gnu.org at billz dot fastmail.fm
2023-01-10 13:22 ` i.nixman at autistici dot org
2023-01-10 13:25 ` gnu.org at billz dot fastmail.fm
2023-01-10 13:49 ` i.nixman at autistici dot org
2023-01-10 14:54 ` gnu.org at billz dot fastmail.fm
2023-01-10 18:57 ` i.nixman at autistici dot org
2023-01-10 20:52 ` i.nixman at autistici dot org
2023-01-10 21:31 ` gnu.org at billz dot fastmail.fm
2023-01-12 19:24 ` i.nixman at autistici dot org
2023-01-13 10:28 ` gnu.org at billz dot fastmail.fm
2023-01-13 10:32 ` i.nixman at autistici dot org
2023-01-13 10:34 ` i.nixman at autistici dot org
2023-01-13 10:43 ` gnu.org at billz dot fastmail.fm
2023-01-13 10:43 ` gnu.org at billz dot fastmail.fm
2023-01-13 11:04 ` gnu.org at billz dot fastmail.fm
2023-01-13 11:19 ` gnu.org at billz dot fastmail.fm
2023-01-16 8:51 ` i.nixman at autistici dot org
2023-01-16 13:42 ` gnu.org at billz dot fastmail.fm
2023-01-16 13:52 ` i.nixman at autistici dot org
2023-01-16 14:22 ` i.nixman at autistici dot org
2023-01-16 17:07 ` i.nixman at autistici dot org
2023-01-16 17:27 ` gnu.org at billz dot fastmail.fm
2023-01-16 17:30 ` i.nixman at autistici dot org
2023-01-16 18:08 ` i.nixman at autistici dot org
2023-01-16 19:31 ` i.nixman at autistici dot org
2023-01-18 19:58 ` gnu.org at billz dot fastmail.fm
2023-01-18 20:08 ` gnu.org at billz dot fastmail.fm
2023-01-18 20:24 ` i.nixman at autistici dot org
2023-01-23 11:44 ` gnu.org at billz dot fastmail.fm
2023-01-23 11:50 ` i.nixman at autistici dot org
2023-01-23 11:51 ` i.nixman at autistici dot org
2023-01-24 0:02 ` gnu.org at billz dot fastmail.fm
2023-02-11 8:36 ` 10walls at gmail dot com
2023-02-11 8:51 ` gerald at pfeifer dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).