GNU bug report logs - #25633
porting gzip to Visual Studio 2015 failed due to redesign of CRT

Previous Next

Package: gzip;

Reported by: Kees Dekker <Kees.Dekker <at> infor.com>

Date: Mon, 6 Feb 2017 16:35:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #26 received at 25633 <at> debbugs.gnu.org (full text, mbox):

From: Kees Dekker <Kees.Dekker <at> infor.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Eric Blake <eblake <at> redhat.com>, "bug-gnulib <at> gnu.org" <bug-gnulib <at> gnu.org>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
Subject: RE: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Date: Tue, 7 Feb 2017 14:13:09 +0000
[Message part 1 (text/plain, inline)]
Hi Bruno,

>Most of these troubles should go away if you use the 'compile' and 'ar-lib'
>auxiliary scripts, as described in section 2 of
>http://git.savannah.gnu.org/gitweb/?p=gperf.git;a=blob_plain;f=README.windows

>These instructions were tested with GNU gperf and a couple of other GNU
>packages. They should be applicable to GNU gzip as well.

This is great information. It would be nice to ship a README.windows together with the gzip sources.
Grosso modo I'm building in the way described, but put my files into Visual Studio project.

Based on what I found today: the changes at low-level stdio in the FILE struct are now complable (I did not have yet a chance to let pass gzip our own internal tests, will do so later today or tomorrow).
But still some things are incorrect:

1.      frexp.c is not needed, as Visual Studio already provides frexp() function via system libraries.
2.      memchr.c is not needed, as Visual Studio already provides memchr() function via system libraries.
3.      gzip.c/h, util.c: the strlwr() function conflicts with Visual Studio one. Added HAVE_STRLWR define in config.h and omit implementation + prototype.
4.      lseek.c: need to include winsock2.h before including windows.h
5.      utimens.c: need to include sys/times.c on Windows to get struct utimbuf + need to define HAVE_STRUCT_UTIMBUF in config.h +
6.      unzip.c: added xalloc.h to have consistent prototype for xalloc-die() (and removed this prototype from gzip.h). See also #9 which probably explains why a prototype exists in two places? Anyhow, util.c already included xalloc.h.
7.      config.h (stored in clearcase as config_win32.h): added typedefs for uid_t and gid_t.
8.      tailor.h/utimes.c: HAVE_SYS_UTIME_H is defined, but not used. Should this not become part of configure and add HAVE_SYS_UTIME_H define in config.h + adjust code in utimens.c?
9.      util.c/xalloc-die.c: both contain a xalloc_die() function. I guess this is intentionally?

For t#1, #2, #3, #5, #7, #8: I lack the knowledge to adjust configure in such way that correct defines in config.h are generated. Also the source code need to be adjusted (rely on system headers instead of own prototypes if there is a working 'system' counterpart. I added myself HAVE_STRLWR in config.h.

The #4 is IMO a bug. It is required to include winsock2.h before including windows.h for recent Visual Studio versions.
The same applies to #6: the prototype for xalloc_die () exists in gzip.h and xalloc.h, but differs (regarding _Neturn attribute and ATTRIBUTE_NORETURN suffix. IMO unzip.c should include xalloc.h and gzip.h should not contain a prototype for xalloc().

Regarding #8: I added a few lines in utimens.c:37:

#if HAVE_UTIME_H
# include <utime.h>
#elif HAVE_SYS_UTIME_H
# include <sys/utime.h>
#endif

On Windows/Visual Studio sys/utime.h defines struct utimebuf (so HAVE_STRUCT_UTIMBUF need to be defines as well in config.h). But it would be nice if configure detects this.

>It is in this step 'c' that the 'compile' auxiliary script becomes useful.

Finaly I've a gzip.exe using native Visual Stduio libraries. And at least it starts :):

      gzip --version
      gzip 1.8.18-00e6
      Copyright (C) 2016 Free Software Foundation, Inc.
      Copyright (C) 1993 Jean-loup Gailly.
      This is free software.  You may redistribute copies of it under the terms of
      the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
      There is NO WARRANTY, to the extent permitted by law.

      Written by Jean-loup Gailly.

So thanks all for your help.

Kees

[Message part 2 (text/html, inline)]

This bug report was last modified 3 years and 112 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.