RE: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT

[Kees Dekker]

>Are the mentioned patches in the snapshot that was provided by Jim?
>In any case, I will check today. Thanks for prompt replies.

>If you like, I can share some additional changes I've made, e.g. Visual Studio 
>does not like -g flag, a WIN32 define that should be _WIN32 (a CL.exe built-in 
>macro), a workaround for missing #include_next directive (which >is not 
>supported by Visual Studio), a struct that is in sys/time.h instead of time.h 
>(utimens.c). Please let me know the preferred format of changed. Is a UNIX 
>style patch ok (using gzip-1.8.18-00e6 as reference)?

>I'm not familiar enough with configure to be able to add 'auto-detect' rules 
>for e.g. adding a HAVE_SYS_UTIME_H directive (needed in utimens.c to get 
>struct utimbuf). The same applies to detect whether -g flag is (not) 
>>supported by the used compiler.

Sorry, I forgot to tell one other issue (with the risk of confusing others):
Inconsistent usage in xalloc.h:56 about _Noreturn and gzip.h:325: 
ATTRIBUTE_NORETURN.
I would suggest to require to include xalloc.h if you need to use xalloc() or 
variants and not adding the same prototype in gzip.h. This requires to add 
xalloc.h in some places.
Visual Studio 2015 complains about different linkage if these two prototypes 
will be mixed.

>Background: I tried to get the Visual Studio build working by performing the 
>following steps:
>a. open a Visual Studio command prompt (that have set LIB, INCLUDE etc 
>environment variables)
>b. from within this prompt, start Cygwin shell
>c. run CC=cl.exe ./configure
>d. import result into a visual studio project file (this step is only needed 
>for us to incorporate the gzip build in our own build).

Regards,
Kees