[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign
RE: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT
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
Background: I tried to get the Visual Studio build working by performing the
a. open a Visual Studio command prompt (that have set LIB, INCLUDE etc
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).