Re: [PATCH] compat/regex: fix compilation on Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

> I'd place a bet on this part of compat/mingw.h for GCC builds:
>
> 	#ifdef __MINGW64_VERSION_MAJOR
> 	#include <stdint.h>
> 	#include <wchar.h>
> 	typedef _sigset_t sigset_t;
> 	#endif
>
> and on this part of git-compat-util.h for MSVC builds:
>
> 	#ifndef NO_INTTYPES_H
> 	#include <inttypes.h>
> 	#else
> 	#include <stdint.h>
> 	#endif

Yeah, but I had an impression that git-compat-util.h was not in use
to build compat/regex/regex.o (regex.c #include's regcomp.c which is
a rather unusual arragement), and that was why I am wondering.

> For the record, it seems that our current version of compat/regex/regex.c
> has this:
>
> 	/* On some systems, limits.h sets RE_DUP_MAX to a lower value than
> 	   GNU regex allows.  Include it before <regex.h>, which correctly
> 	   #undefs RE_DUP_MAX and sets it to the right value.  */
> 	#include <limits.h>
> 	#include <stdint.h>
>
> while the one in `pu` lacks the last line. That may be the reason why
> things compiled neatly before, and stopped working for you now.

Yes, that explains how the old one worked and the new one didn't
without dropping "#ifdef HAVE_STDINT_H".

Thanks.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]