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 <nat...@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
>
