https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |egallager at gcc dot gnu.org
Status|SUSPENDED |UNCONFIRMED
Ever confirmed|1 |0
--- Comment #5 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to simon from comment #4)
> (In reply to Eric Botcazou from comment #2)
>
> When I said in comment 1
>
> >I have to say that, great as it would be to have this fixed, the changes
> >required would be extensive, and I can’t see that anyone would think it
> >worth the trouble.
>
> I meant that coping with macOS’s HFS+ behaviour w.r.t. NFC vs NFD was
> something it’d be unreasonable to spend effort on fixing.
>
> The main point of this PR is that you can’t use extended characters in
> unit names on case-insensitive filesystems, *which includes Windows*.
> Fixing that problem (I can see it might mean introducing a new adaint.c
> interface "is filesystem UTF8?") would be a good thing. Can the compiler
> use iconv? or Ada.Wide_Characters.Handling,
> Ada.Strings.UTF_Encoding.[Wide_]Strings?
>
> The awkwardness discussed in comment 1 isn’t really a problem except
> when compiling the offending unit from the command line; when compiled
> as part of the closure by gnatmake there’s no problem, I guess gnatmake
> reads the unit name in NFC and gets the file name in NFD from the file
> system.
>
> I think there _is_ a problem in gprbuild but of course that’s nothing
> to do with GCC.
>
> Please can this PR be reopened?
Well, it was never closed in the first place, just marked as SUSPENDED, but I
can put it back to UNCONFIRMED, I guess...
