Re: gcov patch, multiple paths

[Alen Skondro <askondro at gmail dot com>]

This breaks the mingw64 build with S_ISLNK being unresolved.

Since windows doesn't know anything about symbolic links, could
something like this help?

diff --git a/gcc/config/i386/xm-mingw32.h b/gcc/config/i386/xm-mingw32.h
index e0dd3f3..34663ac 100644
--- a/gcc/config/i386/xm-mingw32.h
+++ b/gcc/config/i386/xm-mingw32.h
@@ -33,3 +33,7 @@ along with GCC; see the file COPYING3.  If not see
 /* MSVCRT does not support the "ll" format specifier for printing
    "long long" values.  Instead, we use "I64".  */
 #define HOST_LONG_LONG_FORMAT "I64"
+
+/* Windows doesn't know about symbolic links. */
+#define S_ISLNK(x) false
+

On Sat, Nov 12, 2011 at 12:45, Nathan Sidwell <nathan@acm.org> wrote:
> Hi,
> I've committed this patch to gcov, ÂIt deals with cases where the same
> header file, containing inline functions etc, is included by multiple
> different pathnames. ÂThe current behavior treats these as distinct sources,
> which is (a) misleading and (b) in the absence of -p all but one instance of
> the resulting .gcov file will be overwritten.
>
> We now canonicalize the names of source files by eliding '.' components
> always and eliding 'dir/..' components where possible. ÂWe can't resolve a
> 'dir/..' component when 'dir' is a symlink. ÂWe also canonicalize \\ path
> separators.
>
> I discovered some faults with the preserve-pathname mangling, in that it
> didn't match the documented behaviour ('.' wasn't elided, and /../ turned
> into '#..#^'. ÂThese are fixed with this patch too.
>
> I updated the documentation to make it clear you can provide either source
> or object filenames to gcov. ÂHistorically it accepted source files, but
> with current inlining and C++ features, it makes more sense to provide the
> object file names, especially in multi-directory builds.
>
> tested on i686-pc-linux-gnu
>