https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
--- Comment #4 from simon at pushface dot org --- (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?
