https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
Gerald Pfeifer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #36 from Bill Zissimopoulos ---
(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?
>
> gr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #35 from niXman ---
and the rights to edit my comments too =)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #34 from niXman ---
(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 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #33 from Bill Zissimopoulos ---
Now that we have a potential patch what are the steps to get it included into
the gcc codebase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #32 from niXman ---
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #31 from Bill Zissimopoulos ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #30 from Bill Zissimopoulos ---
(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)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #29 from niXman ---
Created attachment 54285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54285&action=edit
patch
another version of the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #28 from niXman ---
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #27 from niXman ---
ah, got it.
thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #26 from Bill Zissimopoulos ---
(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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #25 from niXman ---
updated patch there:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #24 from niXman ---
BTW, I have no ideas how can I test the patch for UNC ('\\?\UNC' prefixed) ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #23 from niXman ---
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 Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #22 from Bill Zissimopoulos ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #21 from niXman ---
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 `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #20 from Bill Zissimopoulos ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #19 from Bill Zissimopoulos ---
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 ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #18 from Bill Zissimopoulos ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #17 from Bill Zissimopoulos ---
(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/question
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #16 from niXman ---
Created attachment 54264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54264&action=edit
patch
the patch for `lrealpath()` for win32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #15 from niXman ---
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #14 from Bill Zissimopoulos ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #13 from niXman ---
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...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #12 from Bill Zissimopoulos ---
(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 o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #11 from niXman ---
even with a downgraded host toolchain to that which uses mingw-w64 rt-v9 I get
the same error...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #10 from niXman ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #9 from Bill Zissimopoulos ---
Thank you.
Let me know if you need any help from me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #8 from niXman ---
> 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 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #7 from Bill Zissimopoulos ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #6 from niXman ---
> 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...?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #5 from Bill Zissimopoulos ---
(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
> > `GetF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #4 from niXman ---
> 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 `GetFinalP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #3 from niXman ---
(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 `GetFullPathNam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #2 from Bill Zissimopoulos ---
(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!
> wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #1 from niXman ---
> FIX
>
> The most straightforward fix is to change `lrealpath` to use
> `GetFinalPathNameByHandle` instead of `GetFullPathName`.
thanks for the investigation!
will do it now.
38 matches
Mail list logo
