Hi,
On 04/01/2014 05:17 AM, Joey Ye wrote:
> diff --git a/libcpp/files.c b/libcpp/files.c
> index 7e88778..ad68682 100644
> --- a/libcpp/files.c
> +++ b/libcpp/files.c
> @@ -387,8 +387,14 @@ find_file_in_dir (cpp_reader *pfile, _cpp_file *file,
> bool *invalid_pch)
> char *copy;
> void **pp;
>
> - /* We try to canonicalize system headers. */
> - if (CPP_OPTION (pfile, canonical_system_headers) && file->dir->sysp)
> + /* We try to canonicalize system headers. For DOS based file
> + * system, we always try to shorten non-system headers, as DOS
> + * has a tighter constraint on max path length. */
> + if (CPP_OPTION (pfile, canonical_system_headers) && file->dir->sysp
> +#ifdef HAVE_DOS_BASED_FILE_SYSTEM
> + || !file->dir->sysp
> +#endif
> + )
> {
> char * canonical_path = maybe_shorter_path (path);
Recently I have been working with a Windows GCC user that is running into the
minuscule Windows path limits discussed here. I backported this patch to see
if it helped their case, but it didn't.
The problem we ran into is that 'lrealpath' is used in 'maybe_shorter_path' to
compute the canonical file path that has the relative portions removed. On
Windows the implementation uses 'GetFullPathName'. Unfortunately,
'GetFullPathName' suffers from the same MAX_PATH limit thus the
canonicalization fails (and from what I can tell the relative path that is
passed to 'GetFullPathName' is below the limit, but the joining of the current
working directory with the relative path name passed is not).
Did y'all run into anything like this? Were other options to produce a
canonical path name discussed? Nothing obvious jumped out at me. Despite the
limits, using 'GetFullPathName' seems like the natural way to handle it because
it knows about all the various Windows file system quirks.
--
Meador Inge
CodeSourcery / Mentor Embedded
