https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #10 from Oliver Old <Oliver.Old at loewen dot de> --- (In reply to Pali Rohár from comment #9) > To allow "legacy" (non-WinAPI) functions like open() to operate with long > paths, it is required to set "longPathAware" property into EXE file. Actually, this is required for all file functions, even the Win32 Unicode (with W suffix) functions. The only way to handle long paths without the manifest property is by prepending the extended path syntax (\\?\) before calling the functions. Be aware though, that disables preprocessing of the path with filter drivers, so the path has to work as-is within the file system driver. I'm guessing something like that is done in Cygwin since I was told long paths just work there. > But it is quite hard because of complicated nature how new EXE properties > are being set: property is at specified XML path of XML manifest; XML > manifest is linked to resource node; all nodes are accessible from PE > resource root; PE resource is linked to PE resource directory entry which is > in the Optional PE header. GNU linker can already merge PE resource nodes at > link time. But as new properties are in XML stanzas, it would be needed from > linker to do XML merging. There already is a winnt-utf8.manifest manifest file for MinGW builds. I don't know how that works, but the new property could be added to that one. That shouldn't break anything.
