[Top][All Lists]

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

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

From: Kees Dekker
Subject: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT
Date: Tue, 7 Feb 2017 07:50:15 +0000

>gnulib has been updated to work with this platform on 2016-12-13, see

>Eric Blake replied:
>> If you can help port gnulib to the newer visual studio 2015, I'm sure
>> patches are welcome.
>> ...
>> we welcome patches to catch back up to the current state of things.

>While in general this is a good advise, in this case it's not needed. All
>the reporter needs is a new gzip snapshot tarball that uses gnulib version
>2016-12-14 or newer.

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.

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]