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
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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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=115189
--- Comment #4 from Bill Zissimopoulos ---
The lrealpath function on Windows uses the GetFinalPathNameByHandleW function
with the VOLUME_NAME_DOS flag.
I do not currently have access to a Windows system with dev tools, but my
recollection is th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #6 from Bill Zissimopoulos ---
> I can reproduce the problem with "subst" and with the Windows Explorer
> ("File/Map network drive"). I assume the is the usual way to map network
> drives.
The usual way to map network drives is inde
19 matches
Mail list logo
