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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: gzip; Reported by: Kees Dekker <Kees.Dekker@HIDDEN>; dated Mon, 6 Feb 2017 16:35:02 UTC; Maintainer for gzip is bug-gzip@HIDDEN.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 9 Feb 2017 07:36:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 09 02:36:51 2017
Received: from localhost ([127.0.0.1]:60756 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cbjHe-0007w2-82
	for submit <at> debbugs.gnu.org; Thu, 09 Feb 2017 02:36:51 -0500
Received: from nlsmtpp2.infor.com ([194.149.81.57]:1955)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1cbjHb-0007vp-KV
 for 25633 <at> debbugs.gnu.org; Thu, 09 Feb 2017 02:36:48 -0500
X-SBRS: None
X-IronPort-AV: E=Sophos;i="5.35,349,1484002800"; d="scan'208";a="221140586"
From: Kees Dekker <Kees.Dekker@HIDDEN>
To: Bruno Haible <bruno@HIDDEN>
Subject: RE: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Topic: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Index: AdKAjV9xNYDVluqbRv+HzxvzT19asgADeQuAAAQECAAAGndhgAAJcNoAAAI0i7AARDJDgAAUYtfQ
Date: Thu, 9 Feb 2017 07:36:28 +0000
Message-ID: <858F859BB4F2824EBAB5D4ED58214CB7016A4529F0@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <1820635.toCcZjP9Xg@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>
 <1878656.kSMgZPSmU2@omega>
In-Reply-To: <1878656.kSMgZPSmU2@omega>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.104.139]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 25633
Cc: Eric Blake <eblake@HIDDEN>, "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hi Bruno,

Thanks for reply.

>> 1.      frexp.c is not needed, as Visual Studio already provides frexp()=
 function via system libraries.

...

>Do you have data that shows that MSVC14's frexp() behaves better than the =
one in MSVC 9?

Do you have advice how I can check this quickly? Visual Studio 2015 is VC14=
, so may be 5 versions ahead, something may be fixed? If you have a test co=
de, I will check for you.

>> 4.      lseek.c: need to include winsock2.h before including windows.h

>I'm not observing this problem with building this gzip snapshot.

I have used configure to let it generate the required headers, but finally,=
 all was imported in a visual studio project, so my final compile is using =
visual studio itself (and therefore may be using slightly different default=
s, as I use some base property sheets to globally define some settings, e.g=
. whole program optimization for optimized builds and some other defines an=
d settings).

>> 5.      utimens.c: need to include sys/times.c on Windows to get struct =
utimbuf + need to define HAVE_STRUCT_UTIMBUF in config.h +

>Likewise: I'm not observing this problem.

Probably same cause, due to my native visual studio compilation.

>> 7.      config.h (stored in clearcase as config_win32.h): added typedefs=
 for uid_t and gid_t.

>config.h is autogenerated with my README.windows instructions.

There is no README.windows file in the tar.gz file of the gzip sources, so =
it would be very handy to add it there. This email chain told me that there=
 is something like README.windows for gnulib....

>> 9.      util.c/xalloc-die.c: both contain a xalloc_die() function. I gue=
ss this is intentionally?

>The one in util.c is meant to override the one from gnulib. This is normal=
ly achieved by having the gnulib code linked as a library.

But it IMO still strange to have two different prototypes for a similar fun=
ction (that got implemented in two places). If these are harmonized, then t=
here is no problem. The order of including header files may now conflict wi=
th the implementation that comes first...

Kees




Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 8 Feb 2017 22:44:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 08 17:44:51 2017
Received: from localhost ([127.0.0.1]:60609 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cbayp-0002OI-3M
	for submit <at> debbugs.gnu.org; Wed, 08 Feb 2017 17:44:51 -0500
Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.161]:30633)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bruno@HIDDEN>) id 1cbayn-0002O8-2U
 for 25633 <at> debbugs.gnu.org; Wed, 08 Feb 2017 17:44:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486593887;
 l=2261; s=domk; d=clisp.org;
 h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:
 In-Reply-To:Date:Subject:Cc:To:From;
 bh=FkztXOL/mKMlqBcDf+MfezxeyB5exYXOAM0XEsHzGtI=;
 b=AzEOSTfw55rp3EJJMrC8Ye6ulQFVzQFMCFW7o5YIkQEVRuwtK1+cVWUy4ghUUt48aI
 de6aNA+emz+RVqDAyNUUdhkRsZUvRJQ2i6u3m4V3JgtqCOSYf0KnRaywSGvb0bqDppW5
 5uwtOPaQNgvaw307ZD0DWO9Vs3j99iUrb68+s=
X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRavU46kji
X-RZG-CLASS-ID: mo00
Received: from bruno.haible.de
 (dslb-088-068-033-080.088.068.pools.vodafone-ip.de [88.68.33.80])
 by smtp.strato.de (RZmta 39.12 DYNA|AUTH)
 with ESMTPSA id h00fa8t18MijlBh
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH
 bits, eq. 15360 bits RSA)) (Client did not present a certificate);
 Wed, 8 Feb 2017 23:44:45 +0100 (CET)
From: Bruno Haible <bruno@HIDDEN>
To: Kees Dekker <Kees.Dekker@HIDDEN>
Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Date: Wed, 08 Feb 2017 23:44:45 +0100
Message-ID: <1878656.kSMgZPSmU2@omega>
User-Agent: KMail/5.1.3 (Linux/4.4.0-62-generic; KDE/5.18.0; x86_64; ; )
In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <1820635.toCcZjP9Xg@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 25633
Cc: Eric Blake <eblake@HIDDEN>, "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Hi Kees,

> 1.      frexp.c is not needed, as Visual Studio already provides frexp() function via system libraries.

The configure log says:
checking whether frexp works... guessing no
...
checking whether frexpl works... guessing no

Why "guessing"? Apparently AC_RUN_IFELSE refuses to run the
test program when compiling to mingw on a Cygwin host. Argh.

But it's documented in doc/posix-functions/frexp.texi
https://www.gnu.org/software/gnulib/manual/html_node/frexp.html

Do you have data that shows that MSVC14's frexp() behaves better than
the one in MSVC 9?

> 2.      memchr.c is not needed, as Visual Studio already provides memchr() function via system libraries.

The configure log says:
checking whether memchr works... guessing no
Again the AC_RUN_IFELSE problem.

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

That makes you depend on what Microsoft happens to implement in its
library. https://msdn.microsoft.com/en-us/library/ms235455.aspx

> 4.      lseek.c: need to include winsock2.h before including windows.h

I'm not observing this problem with building this gzip snapshot.

> 5.      utimens.c: need to include sys/times.c on Windows to get struct utimbuf + need to define HAVE_STRUCT_UTIMBUF in config.h +

Likewise: I'm not observing this problem.

> 7.      config.h (stored in clearcase as config_win32.h): added typedefs for uid_t and gid_t.

config.h is autogenerated with my README.windows instructions.

> 9.      util.c/xalloc-die.c: both contain a xalloc_die() function. I guess this is intentionally?

The one in util.c is meant to override the one from gnulib. This is normally
achieved by having the gnulib code linked as a library.

My build attempt aborted like this:
C:\cygwin64\home\bruno\gzip-1.8.18-00e6\gzip.c(1900): error C2146: syntax error: missing ')' before identifier 'uid'
C:\cygwin64\home\bruno\gzip-1.8.18-00e6\gzip.c(1900): error C2081: 'uid_t': name in formal parameter list illegal
C:\cygwin64\home\bruno\gzip-1.8.18-00e6\gzip.c(1900): error C2061: syntax error: identifier 'uid'
Indeed all uses of uid_t and gid_t need to be revisited when porting to native Windows.

Bruno





Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 8 Feb 2017 16:03:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 08 11:03:20 2017
Received: from localhost ([127.0.0.1]:60434 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cbUiF-0008IZ-CH
	for submit <at> debbugs.gnu.org; Wed, 08 Feb 2017 11:03:19 -0500
Received: from nlsmtpp2.infor.com ([194.149.81.57]:50018)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1cbUiD-0008IJ-8Y
 for 25633 <at> debbugs.gnu.org; Wed, 08 Feb 2017 11:03:17 -0500
X-SBRS: None
X-IronPort-AV: E=Sophos;i="5.33,348,1477954800"; 
 d="scan'208,217";a="220976016"
From: Kees Dekker <Kees.Dekker@HIDDEN>
To: Bruno Haible <bruno@HIDDEN>
Subject: RE: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Topic: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Index: AdKAjV9xNYDVluqbRv+HzxvzT19asgADeQuAAAQECAAAGndhgAAJcNoAAAI0i7AAAG85gAA2t9SA
Date: Wed, 8 Feb 2017 16:03:10 +0000
Message-ID: <858F859BB4F2824EBAB5D4ED58214CB7016A4525BC@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <2310163.ep0zRcYtDC@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@HIDDEN>
 <1820635.toCcZjP9Xg@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>
 <544a9cca-f88d-5d66-f45d-9d7f6825f64e@HIDDEN>
In-Reply-To: <544a9cca-f88d-5d66-f45d-9d7f6825f64e@HIDDEN>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.104.139]
Content-Type: multipart/alternative;
 boundary="_000_858F859BB4F2824EBAB5D4ED58214CB7016A4525BCNLBAWEXMBX3in_"
MIME-Version: 1.0
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 25633
Cc: "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A4525BCNLBAWEXMBX3in_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Pj4gMS4gICAgICBmcmV4cC5jIGlzIG5vdCBuZWVkZWQsIGFzIFZpc3VhbCBTdHVkaW8gYWxyZWFk
eSBwcm92aWRlcyBmcmV4cCgpIGZ1bmN0aW9uIHZpYSBzeXN0ZW0gbGlicmFyaWVzLg0KDQo+QnV0
IHByb2JhYmx5IHdpdGggYnVncy4gIEFuZCBldmVuIGlmIGl0IGlzIG5vdCBuZWVkZWQgb24geW91
ciBwbGF0Zm9ybSwNCj5pdCBpcyBwYXJ0IG9mIHRoZSB0YXJiYWxsIHRvIHJlcGxhY2UgYnJva2Vu
IGZyZXhwKCkgb24gc3lzdGVtcyB3aGVyZSBpdA0KPmlzIGJ1Z2d5LiAgUGFydCBvZiBjb25maWd1
cmUgZGV0ZXJtaW5lcyBpZiBpdCBpcyBuZWVkZWQgb24geW91ciBwbGF0Zm9ybS4NCg0KUG9zc2li
bHksIGJ1dCB3aHkgaXMgdGhlIGNoYW5jZSBvbiBidWdzIG9uIE1pY3Jvc29mdCdzIGZyZXhwKCkg
aGlnaGVyPyBUaGUgb25seSAodW5mb3J0dW5hdGVseSBjb21tb24pIHByYWN0aWNlIG9mIE1pY3Jv
c29mdCBpcyB0aGF0IHRoZXkgbWF5IGRpZmZlciBmcm9tICdzdGFuZGFyZCcgYmVoYXZpb3Igb24g
TGludXguDQoNCj5JJ20gbGVzcyBjZXJ0YWluIG9uIHRoZSBzb2x1dGlvbnMgZm9yIHRoZSBvdGhl
cnMsIGFsdGhvdWdoIHBhdGNoZXMgdG8NCj5nbnVsaWIgYXJlIHdlbGNvbWUuDQoNCkknbSBub3Qg
c3VyZSB3aGV0aGVyIEkndmUgdGhlIGtub3dsZWRnZSB0byBkbyBzbywgYnV0IHRvZGF5IEkgdHJp
ZWQgdG8gZ2V0IGdkaWZmIGFsc28gY29tcGlsYWJsZSBpbiBDeWd3aW4gc2hlbGwgKHdpdGggYWxs
IHJlcXVpcmVkIGVudmlyb25tZW50IHZhcmlhYmxlcyB1c2VkIGJ5IFZpc3VhbCBTdHVkaW8ncyBj
bC5leGUgcHJvcGVybHkgc2V0KSArIENDPWNsLmV4ZSAuL2NvbmZpZ3VyZQ0KQW5kIGZ1bm55IGVu
b3VnaCwgSSdtIHJlY29nbml6aW5nIHRoaW5ncy4gR2RpZmYgYWxzbyB1c2VzIGdudWxpYi4gQSBw
aWVjZSBvZiB0aGUgb3V0cHV0IGlzOg0KDQogICAgICBjaGVja2luZyBhYnNvbHV0ZSBuYW1lIG9m
IDx3Y2hhci5oPi4uLiAiIg0KDQpTbyBpZiBhIHN5c3RlbSBoZWFkZXIgaXMgbm90IGZvdW5kLCBp
dCBleHBhbmRzIHRvIGFuIGVtcHR5IHN0cmluZy4gQmVjYXVzZSBNaWNyb3NvZnQgVmlzdWFsIFN0
dWRpbyBkb2VzIG5vdCByZWNvZ25pemUgdGhlIGluY2x1ZGVfbmV4dCBwcmFnbWEsIEkgdXNlZCB0
aGUgZm9sbG93aW5nIHRyaWNrOg0KVGhlICNpbmNsdWRlW19uZXh0XSAiIiBkaXJlY3RpdmUgd2Fz
IHJlcGxhY2VkIGJ5ICNpbmNsdWRlICIuLi91Y3J0L2hlYWRlcmZpbGUiLiBUaGlzIHdvcmtzIHdl
bGwgZm9yIHRoZSBXaW5kb3dzIDEwIFNESy4gSWYgYW4gb2xkZXIgVmlzdWFsIFN0dWRpb24gdmVy
c2lvbiBpcyB1c2VkLCB1c2UgI2luY2x1ZGUgIi4uL2luY2x1ZGUvaGVhZGVyZmlsZSIsIHdoZXJl
IDxoZWFkZXJmaWxlPiBjYW4gYmUgcmVwbGFjZWQgYnkgYW55IHN5c3RlbSBoZWFkZXIgKGUuZy4g
d2NoYXIuaCBvciBzeXMvdHlwZXMuaCkuDQoNCldoYXQgaXMgdGhlIHJlY29tbWVuZGVkIHRvIGdl
dCB0aGlzIGJlaGF2aW9yIGNoYW5nZWQ/IEl0IHJlcXVpcmVzIGNoYW5nZXMgaW4gY29uZmlndXJl
IHRvIGRldGVjdCB3aGV0aGVyIGEg4oCYZG90ZG904oCZIGNvbnN0cnVjdCB3b3JrcyBmb3Igdmlz
dWFsIHN0dWRpbyAoYW5kIG9ubHkgb2YgY29tcGlsZXIgbWF0Y2hlcyB3aXRoIGNsWy5leGVdKSBh
bmQgaWYgdGhlIGhlYWRlciBpbmRlZWQgZXhpc3RzIChXaW5kb3dzIGhhcyBlLmcuIG5vIGRpcmVu
dC5oIGFuZCBtdWNoIG90aGVyIFVOSVggc3R5bGUgaGVhZGVycykuDQoNCg0K

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A4525BCNLBAWEXMBX3in_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu
dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt
LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s
ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K
PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+Jmd0OyZndDsgMS4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgZnJleHAuYyBpcyBub3QgbmVlZGVkLCBhcyBWaXN1YWwgU3R1ZGlvIGFscmVh
ZHkgcHJvdmlkZXMgZnJleHAoKSBmdW5jdGlvbiB2aWEgc3lzdGVtIGxpYnJhcmllcy48L2Rpdj4N
CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDtCdXQgcHJvYmFibHkgd2l0aCBidWdzLiZuYnNw
OyBBbmQgZXZlbiBpZiBpdCBpcyBub3QgbmVlZGVkIG9uIHlvdXIgcGxhdGZvcm0sPC9kaXY+DQo8
ZGl2PiZndDtpdCBpcyBwYXJ0IG9mIHRoZSB0YXJiYWxsIHRvIHJlcGxhY2UgYnJva2VuIGZyZXhw
KCkgb24gc3lzdGVtcyB3aGVyZSBpdDwvZGl2Pg0KPGRpdj4mZ3Q7aXMgYnVnZ3kuJm5ic3A7IFBh
cnQgb2YgY29uZmlndXJlIGRldGVybWluZXMgaWYgaXQgaXMgbmVlZGVkIG9uIHlvdXIgcGxhdGZv
cm0uPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Qb3NzaWJseSwgYnV0IHdoeSBpcyB0
aGUgY2hhbmNlIG9uIGJ1Z3Mgb24gTWljcm9zb2Z0J3MgZnJleHAoKSBoaWdoZXI/IFRoZSBvbmx5
ICh1bmZvcnR1bmF0ZWx5IGNvbW1vbikgcHJhY3RpY2Ugb2YgTWljcm9zb2Z0IGlzIHRoYXQgdGhl
eSBtYXkgZGlmZmVyIGZyb20gJ3N0YW5kYXJkJyBiZWhhdmlvciBvbiBMaW51eC48L2Rpdj4NCjxk
aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDtJJ20gbGVzcyBjZXJ0YWluIG9uIHRoZSBzb2x1dGlv
bnMgZm9yIHRoZSBvdGhlcnMsIGFsdGhvdWdoIHBhdGNoZXMgdG88L2Rpdj4NCjxkaXY+Jmd0O2du
dWxpYiBhcmUgd2VsY29tZS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkknbSBub3Qg
c3VyZSB3aGV0aGVyIEkndmUgdGhlIGtub3dsZWRnZSB0byBkbyBzbywgYnV0IHRvZGF5IEkgdHJp
ZWQgdG8gZ2V0IGdkaWZmIGFsc28gY29tcGlsYWJsZSBpbiBDeWd3aW4gc2hlbGwgKHdpdGggYWxs
IHJlcXVpcmVkIGVudmlyb25tZW50IHZhcmlhYmxlcyB1c2VkIGJ5IFZpc3VhbCBTdHVkaW8ncyBj
bC5leGUgcHJvcGVybHkgc2V0KSAmIzQzOyBDQz1jbC5leGUgLi9jb25maWd1cmUgPC9kaXY+DQo8
ZGl2PkFuZCBmdW5ueSBlbm91Z2gsIEknbSByZWNvZ25pemluZyB0aGluZ3MuIEdkaWZmIGFsc28g
dXNlcyBnbnVsaWIuIEEgcGllY2Ugb2YgdGhlIG91dHB1dCBpczo8L2Rpdj4NCjxkaXY+Jm5ic3A7
PC9kaXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPjxpPmNoZWNraW5nIGFic29s
dXRlIG5hbWUgb2YgJmx0O3djaGFyLmgmZ3Q7Li4uICZxdW90OyZxdW90OzwvaT48L2Rpdj4NCjxk
aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlNvIGlmIGEgc3lzdGVtIGhlYWRlciBpcyBub3QgZm91bmQs
IGl0IGV4cGFuZHMgdG8gYW4gZW1wdHkgc3RyaW5nLiBCZWNhdXNlIE1pY3Jvc29mdCBWaXN1YWwg
U3R1ZGlvIGRvZXMgbm90IHJlY29nbml6ZSB0aGUgaW5jbHVkZV9uZXh0IHByYWdtYSwgSSB1c2Vk
IHRoZSBmb2xsb3dpbmcgdHJpY2s6PC9kaXY+DQo8ZGl2PlRoZSAjaW5jbHVkZVtfbmV4dF0gJnF1
b3Q7JnF1b3Q7IGRpcmVjdGl2ZSB3YXMgcmVwbGFjZWQgYnkgI2luY2x1ZGUgJnF1b3Q7Li4vdWNy
dC9oZWFkZXJmaWxlJnF1b3Q7LiBUaGlzIHdvcmtzIHdlbGwgZm9yIHRoZSBXaW5kb3dzIDEwIFNE
Sy4gSWYgYW4gb2xkZXIgVmlzdWFsIFN0dWRpb24gdmVyc2lvbiBpcyB1c2VkLCB1c2UgI2luY2x1
ZGUgJnF1b3Q7Li4vaW5jbHVkZS9oZWFkZXJmaWxlJnF1b3Q7LCB3aGVyZSAmbHQ7aGVhZGVyZmls
ZSZndDsgY2FuIGJlIHJlcGxhY2VkIGJ5IGFueSBzeXN0ZW0gaGVhZGVyDQooZS5nLiB3Y2hhci5o
IG9yIHN5cy90eXBlcy5oKS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PldoYXQgaXMg
dGhlIHJlY29tbWVuZGVkIHRvIGdldCB0aGlzIGJlaGF2aW9yIGNoYW5nZWQ/IEl0IHJlcXVpcmVz
IGNoYW5nZXMgaW4gY29uZmlndXJlIHRvIGRldGVjdCB3aGV0aGVyIGEg4oCYZG90ZG904oCZIGNv
bnN0cnVjdCB3b3JrcyBmb3IgdmlzdWFsIHN0dWRpbyAoYW5kIG9ubHkgb2YgY29tcGlsZXIgbWF0
Y2hlcyB3aXRoIGNsWy5leGVdKSBhbmQgaWYgdGhlIGhlYWRlciBpbmRlZWQgZXhpc3RzIChXaW5k
b3dzIGhhcyBlLmcuIG5vIGRpcmVudC5oDQphbmQgbXVjaCBvdGhlciBVTklYIHN0eWxlIGhlYWRl
cnMpLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L3NwYW4+
PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A4525BCNLBAWEXMBX3in_--




Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 14:24:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 07 09:24:42 2017
Received: from localhost ([127.0.0.1]:58501 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cb6hG-0000D6-Dy
	for submit <at> debbugs.gnu.org; Tue, 07 Feb 2017 09:24:42 -0500
Received: from mx1.redhat.com ([209.132.183.28]:58630)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eblake@HIDDEN>) id 1cb6hD-0000Cp-41
 for 25633 <at> debbugs.gnu.org; Tue, 07 Feb 2017 09:24:41 -0500
Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com
 [10.5.11.28])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 793D7624A9;
 Tue,  7 Feb 2017 14:24:34 +0000 (UTC)
Received: from [10.10.123.32] (unknown [10.10.123.32])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 7FE262D5BF;
 Tue,  7 Feb 2017 14:24:33 +0000 (UTC)
Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
To: Kees Dekker <Kees.Dekker@HIDDEN>, Bruno Haible <bruno@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <2310163.ep0zRcYtDC@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@HIDDEN>
 <1820635.toCcZjP9Xg@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>
From: Eric Blake <eblake@HIDDEN>
Openpgp: url=http://people.redhat.com/eblake/eblake.gpg
Organization: Red Hat, Inc.
Message-ID: <544a9cca-f88d-5d66-f45d-9d7f6825f64e@HIDDEN>
Date: Tue, 7 Feb 2017 08:24:31 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="6mOToVB8eKcSN3CtGJU7iOeCT6POt1j55"
X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.5.110.39]); Tue, 07 Feb 2017 14:24:34 +0000 (UTC)
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 25633
Cc: "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6mOToVB8eKcSN3CtGJU7iOeCT6POt1j55
Content-Type: multipart/mixed; boundary="b35crxl9fqt7f3m8POx80sxAOtJCS9Rj0";
 protected-headers="v1"
From: Eric Blake <eblake@HIDDEN>
To: Kees Dekker <Kees.Dekker@HIDDEN>, Bruno Haible <bruno@HIDDEN>
Cc: "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
Message-ID: <544a9cca-f88d-5d66-f45d-9d7f6825f64e@HIDDEN>
Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <2310163.ep0zRcYtDC@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@HIDDEN>
 <1820635.toCcZjP9Xg@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>
In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>

--b35crxl9fqt7f3m8POx80sxAOtJCS9Rj0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/07/2017 08:13 AM, Kees Dekker wrote:
> 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 o=
ur own internal tests, will do so later today or tomorrow).
> But still some things are incorrect:
>=20
> 1.      frexp.c is not needed, as Visual Studio already provides frexp(=
) function via system libraries.

But probably with bugs.  And even if it is not needed on your platform,
it is part of the tarball to replace broken frexp() on systems where it
is buggy.  Part of configure determines if it is needed on your platform.=


> 2.      memchr.c is not needed, as Visual Studio already provides memch=
r() function via system libraries.

Likewise.

> 3.      gzip.c/h, util.c: the strlwr() function conflicts with Visual S=
tudio 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 probab=
ly 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 typedef=
s for uid_t and gid_t.
> 8.      tailor.h/utimes.c: HAVE_SYS_UTIME_H is defined, but not used. S=
hould this not become part of configure and add HAVE_SYS_UTIME_H define i=
n config.h + adjust code in utimens.c?
> 9.      util.c/xalloc-die.c: both contain a xalloc_die() function. I gu=
ess this is intentionally?
>=20
> For t#1, #2, #3, #5, #7, #8: I lack the knowledge to adjust configure i=
n such way that correct defines in config.h are generated. Also the sourc=
e code need to be adjusted (rely on system headers instead of own prototy=
pes if there is a working 'system' counterpart. I added myself HAVE_STRLW=
R in config.h.

I'm less certain on the solutions for the others, although patches to
gnulib are welcome.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--b35crxl9fqt7f3m8POx80sxAOtJCS9Rj0--

--6mOToVB8eKcSN3CtGJU7iOeCT6POt1j55
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJYmdifAAoJEKeha0olJ0NqXdMH/0bF0nfZ926beec6+MmuBRCZ
+hXCn5JijRxmFj69Zin9l4SRSUQyv37sGkMshEuc3a6LMUJ1H7eazF0voDs3hZ09
s6atPSdE7XxJQy+u45BJuPw8dLq7zHImurrRg0OZEKktmQ/SPE5BdKYcsfGMKDWd
ZQLmpsFZ3vVg4gULdNrOgjbt8NbelybRbNxia8EYhGoi6Pj67o99dsBwWvfd4WnM
89flxvA6TixpI8FmnXJw+try9MIKXQcAlMfoHGnWzlMmYQi69oVuLQdtVV5xCzjS
7Aj8nvcVaprpDMH2HKBJGZs+48sMAQ/qoqVwbzlBEfdr3X14ASIjRiGj1tQJTBM=
=tmGW
-----END PGP SIGNATURE-----

--6mOToVB8eKcSN3CtGJU7iOeCT6POt1j55--




Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 14:14:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 07 09:14:24 2017
Received: from localhost ([127.0.0.1]:58491 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cb6XH-0008Ov-Un
	for submit <at> debbugs.gnu.org; Tue, 07 Feb 2017 09:14:24 -0500
Received: from nlsmtpp2.infor.com ([194.149.81.57]:49814)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1cb6XF-0008Oi-Q0
 for 25633 <at> debbugs.gnu.org; Tue, 07 Feb 2017 09:14:22 -0500
X-SBRS: None
X-IronPort-AV: E=Sophos;i="5.33,346,1477954800"; 
 d="scan'208,217";a="220659136"
From: Kees Dekker <Kees.Dekker@HIDDEN>
To: Bruno Haible <bruno@HIDDEN>
Subject: RE: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Topic: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Index: AdKAjV9xNYDVluqbRv+HzxvzT19asgADeQuAAAQECAAAGndhgAAJcNoAAAI0i7A=
Date: Tue, 7 Feb 2017 14:13:09 +0000
Message-ID: <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <2310163.ep0zRcYtDC@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@HIDDEN>
 <1820635.toCcZjP9Xg@HIDDEN>
In-Reply-To: <1820635.toCcZjP9Xg@HIDDEN>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.104.139]
Content-Type: multipart/alternative;
 boundary="_000_858F859BB4F2824EBAB5D4ED58214CB7016A451BCBNLBAWEXMBX3in_"
MIME-Version: 1.0
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 25633
Cc: Eric Blake <eblake@HIDDEN>, "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A451BCBNLBAWEXMBX3in_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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=3Dgperf.git;a=3Dblob_plain;f=3DREADM=
E.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 togeth=
er 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 str=
uct 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() fu=
nction 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 Studi=
o one. Added HAVE_STRLWR define in config.h and omit implementation + proto=
type.
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 uti=
mbuf + 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 exp=
lains 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 fo=
r uid_t and gid_t.
8.      tailor.h/utimes.c: HAVE_SYS_UTIME_H is defined, but not used. Shoul=
d this not become part of configure and add HAVE_SYS_UTIME_H define in conf=
ig.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 su=
ch 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 t=
here is a working 'system' counterpart. I added myself HAVE_STRLWR in confi=
g.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 an=
d 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_STRUC=
T_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 i=
t 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 t=
erms 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


--_000_858F859BB4F2824EBAB5D4ED58214CB7016A451BCBNLBAWEXMBX3in_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi Bruno,</div>
<div>&nbsp;</div>
<div>&gt;Most of these troubles should go away if you use the 'compile' and=
 'ar-lib'</div>
<div>&gt;auxiliary scripts, as described in section 2 of</div>
<div>&gt;<a href=3D"http://git.savannah.gnu.org/gitweb/?p=3Dgperf.git;a=3Db=
lob_plain;f=3DREADME.windows">http://git.savannah.gnu.org/gitweb/?p=3Dgperf=
.git;a=3Dblob_plain;f=3DREADME.windows</a></div>
<div>&nbsp;</div>
<div>&gt;These instructions were tested with GNU gperf and a couple of othe=
r GNU</div>
<div>&gt;packages. They should be applicable to GNU gzip as well.</div>
<div>&nbsp;</div>
<div>This is great information. It would be nice to ship a README.windows t=
ogether with the gzip sources.</div>
<div>Grosso modo I'm building in the way described, but put my files into V=
isual Studio project.</div>
<div>&nbsp;</div>
<div>Based on what I found today: the changes at low-level stdio in the FIL=
E struct are now complable (I did not have yet a chance to let pass gzip ou=
r own internal tests, will do so later today or tomorrow).</div>
<div>But still some things are incorrect:</div>
<div>&nbsp;</div>
<ol style=3D"margin:0;padding-left:18pt;">
<li>frexp.c is not needed, as Visual Studio already provides frexp() functi=
on via system libraries.</li><li>memchr.c is not needed, as Visual Studio a=
lready provides memchr() function via system libraries.</li><li>gzip.c/h, u=
til.c: the strlwr() function conflicts with Visual Studio one. Added HAVE_S=
TRLWR define in config.h and omit implementation &#43; prototype.</li><li>l=
seek.c: need to include winsock2.h before including windows.h</li><li>utime=
ns.c: need to include sys/times.c on Windows to get struct utimbuf &#43; ne=
ed to define HAVE_STRUCT_UTIMBUF in config.h &#43; </li><li>unzip.c: added =
xalloc.h to have consistent prototype for xalloc-die() (and removed this pr=
ototype from gzip.h). See also #9 which probably explains why a prototype e=
xists in two places? Anyhow, util.c already included xalloc.h.</li><li>conf=
ig.h (stored in clearcase as config_win32.h): added typedefs for uid_t and =
gid_t.</li><li>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 &#43; adjust code in utimens.c?</li><li>util.c/xalloc-die.c: bo=
th contain a xalloc_die() function. I guess this is intentionally?</li></ol=
>
<div>&nbsp;</div>
<div>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.</div>
<div>&nbsp;</div>
<div>The #4 is IMO a bug. It is required to include winsock2.h before inclu=
ding windows.h for recent Visual Studio versions.</div>
<div>The same applies to #6: the prototype for xalloc_die () exists in gzip=
.h and xalloc.h, but differs (regarding _Neturn attribute and ATTRIBUTE_NOR=
ETURN suffix. IMO unzip.c should include xalloc.h and gzip.h should not con=
tain a prototype for xalloc().</div>
<div>&nbsp;</div>
<div>Regarding #8: I added a few lines in utimens.c:37:</div>
<div>&nbsp;</div>
<div>#if HAVE_UTIME_H</div>
<div># include &lt;utime.h&gt;</div>
<div>#elif HAVE_SYS_UTIME_H</div>
<div># include &lt;sys/utime.h&gt;</div>
<div>#endif</div>
<div>&nbsp;</div>
<div>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 nic=
e if configure detects this.</div>
<div>&nbsp;</div>
<div>&gt;It is in this step 'c' that the 'compile' auxiliary script becomes=
 useful.</div>
<div>&nbsp;</div>
<div>Finaly I've a gzip.exe using native Visual Stduio libraries. And at le=
ast it starts <font face=3D"Wingdings">J</font>:</div>
<div>&nbsp;</div>
<div style=3D"padding-left:36pt;">gzip --version</div>
<div style=3D"padding-left:36pt;">gzip 1.8.18-00e6</div>
<div style=3D"padding-left:36pt;">Copyright (C) 2016 Free Software Foundati=
on, Inc.</div>
<div style=3D"padding-left:36pt;">Copyright (C) 1993 Jean-loup Gailly.</div=
>
<div style=3D"padding-left:36pt;">This is free software.&nbsp; You may redi=
stribute copies of it under the terms of</div>
<div style=3D"padding-left:36pt;">the GNU General Public License &lt;<a hre=
f=3D"http://www.gnu.org/licenses/gpl.html">http://www.gnu.org/licenses/gpl.=
html</a>&gt;.</div>
<div style=3D"padding-left:36pt;">There is NO WARRANTY, to the extent permi=
tted by law.</div>
<div style=3D"padding-left:36pt;">&nbsp;</div>
<div style=3D"padding-left:36pt;">Written by Jean-loup Gailly. </div>
<div>&nbsp;</div>
<div>So thanks all for your help.</div>
<div>&nbsp;</div>
<div>Kees</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A451BCBNLBAWEXMBX3in_--




Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 13:09:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 07 08:09:05 2017
Received: from localhost ([127.0.0.1]:58407 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cb5W5-0006pv-HM
	for submit <at> debbugs.gnu.org; Tue, 07 Feb 2017 08:09:05 -0500
Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.217]:33732)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bruno@HIDDEN>) id 1cb5W3-0006pd-Hk
 for 25633 <at> debbugs.gnu.org; Tue, 07 Feb 2017 08:09:04 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486472942;
 l=1180; s=domk; d=clisp.org;
 h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:
 In-Reply-To:Date:Subject:Cc:To:From;
 bh=7NbLzq74Aw3kVoOknEUiV5VjR2a4YZmGiTGLUmt+HIQ=;
 b=vNzC1XsJKyY42UotOtG7lmHCIOqJrnsSBb64kpydw/30JadJOq89rU+jDiRp8OqeAG
 OQMu9gWPm/f9Ejq/Of3EWBeIfreJJrOzrx7yizphkCmAVjVKxNV9DcH4pavulbawU5fz
 1mcnpAqgrSZbKAmsBMJRsp5Dse3f9+83vSxvQ=
X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRavU46kji
X-RZG-CLASS-ID: mo00
Received: from bruno.haible.de
 (dslb-088-068-033-080.088.068.pools.vodafone-ip.de [88.68.33.80])
 by smtp.strato.de (RZmta 39.11 DYNA|AUTH)
 with ESMTPSA id 60992ft17D8x7Zm
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH
 bits, eq. 15360 bits RSA)) (Client did not present a certificate);
 Tue, 7 Feb 2017 14:08:59 +0100 (CET)
From: Bruno Haible <bruno@HIDDEN>
To: Kees Dekker <Kees.Dekker@HIDDEN>
Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Date: Tue, 07 Feb 2017 14:08:56 +0100
Message-ID: <1820635.toCcZjP9Xg@HIDDEN>
User-Agent: KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; )
In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <2310163.ep0zRcYtDC@HIDDEN>
 <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 25633
Cc: Eric Blake <eblake@HIDDEN>, "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Hello Kees,

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

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.

> 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

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

Bruno





Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 07:54:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 07 02:54:31 2017
Received: from localhost ([127.0.0.1]:58288 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cb0bf-0006GB-Kc
	for submit <at> debbugs.gnu.org; Tue, 07 Feb 2017 02:54:31 -0500
Received: from nlsmtpp2.infor.com ([194.149.81.57]:59241)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1cb0bd-0006Fw-6A
 for 25633 <at> debbugs.gnu.org; Tue, 07 Feb 2017 02:54:29 -0500
X-SBRS: None
X-IronPort-AV: E=Sophos;i="5.33,345,1477954800"; d="scan'208";a="220570039"
From: Kees Dekker <Kees.Dekker@HIDDEN>
To: Bruno Haible <bruno@HIDDEN>, "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>
Subject: RE: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Topic: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Index: AdKAjV9xNYDVluqbRv+HzxvzT19asgADeQuAAAQECAAAGndhgAAAcXRA
Date: Tue, 7 Feb 2017 07:54:21 +0000
Message-ID: <858F859BB4F2824EBAB5D4ED58214CB7016A4518FA@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@HIDDEN>
 <2310163.ep0zRcYtDC@HIDDEN> 
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.104.139]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 25633
Cc: Eric Blake <eblake@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

>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 St=
udio 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 >i=
s not supported by Visual Studio), a struct that is in sys/time.h instead o=
f time.h (utimens.c). Please let me know the preferred format of changed. I=
s 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' rul=
es 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) >supp=
orted 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 a=
dd xalloc.h in some places.
Visual Studio 2015 complains about different linkage if these two prototype=
s will be mixed.

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

Regards,
Kees





Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 07:50:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 07 02:50:28 2017
Received: from localhost ([127.0.0.1]:58283 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cb0Xj-0006AQ-Ua
	for submit <at> debbugs.gnu.org; Tue, 07 Feb 2017 02:50:28 -0500
Received: from nlsmtpp2.infor.com ([194.149.81.57]:48403)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1cb0Xi-0006A9-2P
 for 25633 <at> debbugs.gnu.org; Tue, 07 Feb 2017 02:50:26 -0500
X-SBRS: None
X-IronPort-AV: E=Sophos;i="5.33,345,1477954800"; d="scan'208";a="220569367"
From: Kees Dekker <Kees.Dekker@HIDDEN>
To: Bruno Haible <bruno@HIDDEN>, "bug-gnulib@HIDDEN" <bug-gnulib@HIDDEN>
Subject: RE: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Topic: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Thread-Index: AdKAjV9xNYDVluqbRv+HzxvzT19asgADeQuAAAQECAAAGndhgA==
Date: Tue, 7 Feb 2017 07:50:15 +0000
Message-ID: <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@HIDDEN>
 <2310163.ep0zRcYtDC@HIDDEN>
In-Reply-To: <2310163.ep0zRcYtDC@HIDDEN>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.104.139]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 25633
Cc: Eric Blake <eblake@HIDDEN>,
 "25633 <at> debbugs.gnu.org" <25633 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)


>gnulib has been updated to work with this platform on 2016-12-13, see
>http://git.savannah.gnu.org/gitweb/?p=3Dgnulib.git;a=3Dcommit;h=3D5506db6b=
006274762bf5ea1d23feb7a9801529c8

>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 Stu=
dio does not like -g flag, a WIN32 define that should be _WIN32 (a CL.exe b=
uilt-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' rule=
s 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) suppor=
ted by the used compiler.

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

Regards,
Kees





Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 6 Feb 2017 20:00:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 06 15:00:56 2017
Received: from localhost ([127.0.0.1]:58085 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1capT6-0004ik-9b
	for submit <at> debbugs.gnu.org; Mon, 06 Feb 2017 15:00:56 -0500
Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.163]:34345)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bruno@HIDDEN>) id 1capT4-0004iZ-0R
 for 25633 <at> debbugs.gnu.org; Mon, 06 Feb 2017 15:00:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1486411252;
 l=983; s=domk; d=clisp.org;
 h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:
 In-Reply-To:Date:Subject:Cc:To:From;
 bh=NgXhcH6D6IAGn80nmiZU/CRapKS/fBrCoXkDOoBegvc=;
 b=VYtoLuRE8+Uobotz9wZsz/6rdM0/ojKFxNKnQwIfWk9Rc3JV1nOE+fJW0JaymIdHCP
 S/NS7yypt0OzSfT298uQk+K417JfFJb//zZLJxBkvNOKcWns/CUv4ZQ/3iBMOvpaQCKK
 fMshQjT+op6CTZJgx14Les4rH8GTBJhZUcTuU=
X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRavU46kji
X-RZG-CLASS-ID: mo00
Received: from bruno.haible.de
 (dslb-088-068-033-080.088.068.pools.vodafone-ip.de [88.68.33.80])
 by smtp.strato.de (RZmta 39.12 DYNA|AUTH)
 with ESMTPSA id U017bet16K0p71n
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH
 bits, eq. 15360 bits RSA)) (Client did not present a certificate);
 Mon, 6 Feb 2017 21:00:51 +0100 (CET)
From: Bruno Haible <bruno@HIDDEN>
To: bug-gnulib@HIDDEN
Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
Date: Mon, 06 Feb 2017 21:00:48 +0100
Message-ID: <2310163.ep0zRcYtDC@HIDDEN>
User-Agent: KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; )
In-Reply-To: <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
 <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 25633
Cc: Eric Blake <eblake@HIDDEN>, 25633 <at> debbugs.gnu.org,
 Kees Dekker <Kees.Dekker@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Kees Dekker wrote:
> > I tried to compile gzip with visual studio 2015. Unfortunately, a few files
> > could not be ported. Microsoft has redesigned the core CRT which affects
> > the visibility of (hidden/internals) of e.g. the FILE type. None of the
> > internals of the FILE type is not visible anymore (contrary to Visual
> > Studio 2013 and before). This affects e.g. freadingc, fpurge.c, fseeko.c,
> > fseterr.c.

gnulib has been updated to work with this platform on 2016-12-13, see
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=5506db6b006274762bf5ea1d23feb7a9801529c8

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.

Bruno





Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 6 Feb 2017 19:41:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 06 14:41:52 2017
Received: from localhost ([127.0.0.1]:58069 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1capAd-0004H3-VQ
	for submit <at> debbugs.gnu.org; Mon, 06 Feb 2017 14:41:52 -0500
Received: from mail-ua0-f196.google.com ([209.85.217.196]:36148)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <meyering@HIDDEN>) id 1capAb-0004Gp-Hq
 for 25633 <at> debbugs.gnu.org; Mon, 06 Feb 2017 14:41:50 -0500
Received: by mail-ua0-f196.google.com with SMTP id f2so8316430uaf.3
 for <25633 <at> debbugs.gnu.org>; Mon, 06 Feb 2017 11:41:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:cc:content-transfer-encoding;
 bh=B5bMGqh+enatZCbCZaryMEO0TLNBaganpsa+azmcHI8=;
 b=oQwakgg0AUJ532RnuW/OqN9TNHQABaX70EqfVuN53KBw1EgfCpaheWPqoqFzMGz8v3
 n5HThnoYH4r68volA7YnP7PyDsynpI3CU/gJYPieIt3VFTKVnRZonhn6hkMH6r8PMz90
 vb8qJFKcjuaxhQWDuXsLTyOramGyrNk7xpHq/xD63iOZTVNgr1ke8EJfgl+T7TQc3y47
 TZ+NVFxrfLqmsKRp8o9fqVzt/x/z9w4yEITRSCB8UC2EE+ShDMWruI/lbdtLqxjUGSVp
 dB62TLD1Apo8KyYdMbmQb3GDbUDoL06LquyaR0Jojey3etmgUzP7GzOI/auEsoJiqyfk
 VLoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
 :date:message-id:subject:to:cc:content-transfer-encoding;
 bh=B5bMGqh+enatZCbCZaryMEO0TLNBaganpsa+azmcHI8=;
 b=ipi5uyQRf1E6ut/zS83/4y3UfGHkIWgO4X00yL+3ripBQbZZYzSoZ55Fh1NxgsysTt
 OGADr2vMckKyr+us7Q3eM2szKIL+eZytai3kc/ljRj7N3B3R7N2TrpsOp2Z4kP08glyM
 phl+NYC8X1ssJNZ0rV/OyoW9iab6rBeAeEDq3tDRUzMZsJzsAogSOGYzx8JFnj5n4+MJ
 4R4NFBPXhyAMLNALHMAYhIHEjQOtOAEJhWCCY54Da0hulPCSDCJr04cYpY7o8+1FDwrG
 V9oxdOC7hSM5nWllpwola8d9yR7QnVNjLxisZbNnuIQJA/lo1ZrPFPI5a9CW15v7PSjH
 6XcA==
X-Gm-Message-State: AIkVDXJ4h37NgSnh6b1IUgte1esZqHizM334aANCPVrHlGHJR7VkJoE0wz85e2r3KuPS/mpUJlWlRKJDJHTPpw==
X-Received: by 10.176.6.167 with SMTP id g36mr5825776uag.97.1486410103705;
 Mon, 06 Feb 2017 11:41:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.5.198 with HTTP; Mon, 6 Feb 2017 11:41:22 -0800 (PST)
In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
From: Jim Meyering <jim@HIDDEN>
Date: Mon, 6 Feb 2017 11:41:22 -0800
X-Google-Sender-Auth: ZaOlNc0LdyvFnbNLnFhQf4xndyc
Message-ID: <CA+8g5KGMfCbuCtjOzUdSCgRb3knmQ8y9iOXO921-A3ydSbQUZw@HIDDEN>
Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
To: Kees Dekker <Kees.Dekker@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 25633
Cc: 25633 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

On Mon, Feb 6, 2017 at 7:28 AM, Kees Dekker <Kees.Dekker@HIDDEN> wrote:
> Hi,
>
> I tried to compile gzip with visual studio 2015. Unfortunately, a few fil=
es could not be ported. Microsoft has redesigned the core CRT which affects=
 the visibility of (hidden/internals) of e.g. the FILE type. None of the in=
ternals of the FILE type is not visible anymore (contrary to Visual Studio =
2013 and before). This affects e.g. freadingc, fpurge.c, fseeko.c, fseterr.=
c.
>
> If something else than gcc/glibc is used, then each change - up to everyt=
hing that the OS/libc/compiler vendor found as useful - may break gzip. Is =
it not bad programming practice to do so?
>
> My questions are:
>
> 1.       why does gzip use and rely on these internals?
>
> 2.       Is it intended that gzip should NOT compile on anything else whe=
re gcc/glibc is not used?
>
> Background information: we are normally just compile gzip to be sure that=
 gzip uses the same bits (64-bit) and same C/C++ runtime (DLLs) as used by =
all our binaries. By using the same compiler, end-users only need to instal=
l one runtime (using vcredistxxx.exe that is shipped with Visual Studio). M=
oving to something else (e.g. pre-compiled gzip) will break this. Also, the=
re is no recent gzip version available using Visual Studio runtime DLLs.

I have just made a snapshot of the latest, so please give that a try:

  https://lists.gnu.org/archive/html/bug-gzip/2017-02/msg00002.html




Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at 25633 <at> debbugs.gnu.org:


Received: (at 25633) by debbugs.gnu.org; 6 Feb 2017 18:05:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 06 13:05:58 2017
Received: from localhost ([127.0.0.1]:58026 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1canfq-00027g-Kb
	for submit <at> debbugs.gnu.org; Mon, 06 Feb 2017 13:05:58 -0500
Received: from mx1.redhat.com ([209.132.183.28]:49282)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eblake@HIDDEN>) id 1canfo-00027S-O1
 for 25633 <at> debbugs.gnu.org; Mon, 06 Feb 2017 13:05:57 -0500
Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com
 [10.5.11.28])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 0C2D561E7C;
 Mon,  6 Feb 2017 18:05:52 +0000 (UTC)
Received: from [10.10.123.32] (unknown [10.10.123.32])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 413D2685CE;
 Mon,  6 Feb 2017 18:05:51 +0000 (UTC)
Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
To: Kees Dekker <Kees.Dekker@HIDDEN>, 25633 <at> debbugs.gnu.org,
 Bug-gnulib <bug-gnulib@HIDDEN>
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
From: Eric Blake <eblake@HIDDEN>
Openpgp: url=http://people.redhat.com/eblake/eblake.gpg
Organization: Red Hat, Inc.
Message-ID: <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@HIDDEN>
Date: Mon, 6 Feb 2017 12:05:49 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="Xb7QfvUuqXPIQc7LbjGWl1PFS6rbFnVML"
X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.5.110.39]); Mon, 06 Feb 2017 18:05:52 +0000 (UTC)
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 25633
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Xb7QfvUuqXPIQc7LbjGWl1PFS6rbFnVML
Content-Type: multipart/mixed; boundary="iJXxuhogML0CaaTpp3XAsb2FspCvdmSQi";
 protected-headers="v1"
From: Eric Blake <eblake@HIDDEN>
To: Kees Dekker <Kees.Dekker@HIDDEN>, 25633 <at> debbugs.gnu.org,
 Bug-gnulib <bug-gnulib@HIDDEN>
Message-ID: <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@HIDDEN>
Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to
 redesign of CRT
References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>

--iJXxuhogML0CaaTpp3XAsb2FspCvdmSQi
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[adding gnulib]

On 02/06/2017 09:28 AM, Kees Dekker wrote:
> Hi,
>=20
> I tried to compile gzip with visual studio 2015. Unfortunately, a few f=
iles could not be ported. Microsoft has redesigned the core CRT which aff=
ects the visibility of (hidden/internals) of e.g. the FILE type. None of =
the internals of the FILE type is not visible anymore (contrary to Visual=
 Studio 2013 and before). This affects e.g. freadingc, fpurge.c, fseeko.c=
, fseterr.c.
>=20
> If something else than gcc/glibc is used, then each change - up to ever=
ything that the OS/libc/compiler vendor found as useful - may break gzip.=
 Is it not bad programming practice to do so?

It may be undesirable programming practice, but it beats the alternative
of not compiling at all, and is forced upon us because we WANT access to
these useful low-level details of FILE streams for optimal behavior,
even though those details are not standardized and therefore not
universally available without resorting to peeking inside the struct.

>=20
> My questions are:
>=20
> 1.       why does gzip use and rely on these internals?

gzip is just using gnulib code; but gnulib does it because there are
some algorithms that really do require more information about the
current state of the FILE's buffers than what you can get through just
the standardized putc/getc interfaces.

If you can help port gnulib to the newer visual studio 2015, I'm sure
patches are welcome.

>=20
> 2.       Is it intended that gzip should NOT compile on anything else w=
here gcc/glibc is not used?

No; gnulib tries to make the various FILE manipulation functions
available on as many platform/compiler combinations as possible.  It's
sometimes an arms race when platforms change, but we welcome patches to
catch back up to the current state of things.

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--iJXxuhogML0CaaTpp3XAsb2FspCvdmSQi--

--Xb7QfvUuqXPIQc7LbjGWl1PFS6rbFnVML
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJYmLr9AAoJEKeha0olJ0Nqa3sIAImz0HTosJpCow2QXC0CFN4V
ciWnq4n3wRZpb5bZmaBNQvDOryfj4FBfwGjfa1p3j0ikq2Kz+rTAALqx0KvHbmmh
H+9SdLuj1AfEcYtpHeBhqdbeT3yeBskSKx0LdwFCs+LLq19fMgTQA/Zn1bcpyGbI
MkCupno45Xkiige2X5GacPXkOqV9Ggrx+s98hCkwy4QWn0zsJOexJghrp3EBWoWI
hZ8tb1vas0Z7xTL/xW9q5ThGpr8FzEP/t+l+RxvyVW75A8yrz3qshMWKxRNrvIC7
6cogvFLwLXnoniIccHX4clQpa/BMC5fvIvSZwBefQ+Z0kUewtrHZQjTzFFqUIfU=
=12+C
-----END PGP SIGNATURE-----

--Xb7QfvUuqXPIQc7LbjGWl1PFS6rbFnVML--




Information forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 6 Feb 2017 16:34:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 06 11:34:54 2017
Received: from localhost ([127.0.0.1]:57985 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1camFh-0008UY-M3
	for submit <at> debbugs.gnu.org; Mon, 06 Feb 2017 11:34:54 -0500
Received: from eggs.gnu.org ([208.118.235.92]:45380)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1calDL-0006yT-Jn
 for submit <at> debbugs.gnu.org; Mon, 06 Feb 2017 10:28:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1calDF-00074x-7L
 for submit <at> debbugs.gnu.org; Mon, 06 Feb 2017 10:28:18 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:43460)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <Kees.Dekker@HIDDEN>)
 id 1calDF-00074t-4z
 for submit <at> debbugs.gnu.org; Mon, 06 Feb 2017 10:28:17 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:36332)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1calDD-0005XG-Iz
 for bug-gzip@HIDDEN; Mon, 06 Feb 2017 10:28:17 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <Kees.Dekker@HIDDEN>) id 1calDA-00073n-DM
 for bug-gzip@HIDDEN; Mon, 06 Feb 2017 10:28:15 -0500
Received: from nlsmtpp2.infor.com ([194.149.81.57]:53884)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <Kees.Dekker@HIDDEN>)
 id 1calDA-00073C-1X
 for bug-gzip@HIDDEN; Mon, 06 Feb 2017 10:28:12 -0500
X-SBRS: None
X-IronPort-AV: E=Sophos;i="5.33,342,1477954800"; 
 d="scan'208,217";a="220409112"
From: Kees Dekker <Kees.Dekker@HIDDEN>
To: "bug-gzip@HIDDEN" <bug-gzip@HIDDEN>
Subject: porting gzip to Visual Studio 2015 failed due to redesign of CRT
Thread-Topic: porting gzip to Visual Studio 2015 failed due to redesign of CRT
Thread-Index: AdKAjV9xNYDVluqbRv+HzxvzT19asg==
Date: Mon, 6 Feb 2017 15:28:08 +0000
Message-ID: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@HIDDEN>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.104.139]
Content-Type: multipart/alternative;
 boundary="_000_858F859BB4F2824EBAB5D4ED58214CB7016A451253NLBAWEXMBX3in_"
MIME-Version: 1.0
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.1 (----)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Mon, 06 Feb 2017 11:34:53 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.1 (----)

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A451253NLBAWEXMBX3in_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I tried to compile gzip with visual studio 2015. Unfortunately, a few files=
 could not be ported. Microsoft has redesigned the core CRT which affects t=
he visibility of (hidden/internals) of e.g. the FILE type. None of the inte=
rnals of the FILE type is not visible anymore (contrary to Visual Studio 20=
13 and before). This affects e.g. freadingc, fpurge.c, fseeko.c, fseterr.c.

If something else than gcc/glibc is used, then each change - up to everythi=
ng that the OS/libc/compiler vendor found as useful - may break gzip. Is it=
 not bad programming practice to do so?

My questions are:

1.       why does gzip use and rely on these internals?

2.       Is it intended that gzip should NOT compile on anything else where=
 gcc/glibc is not used?

Background information: we are normally just compile gzip to be sure that g=
zip uses the same bits (64-bit) and same C/C++ runtime (DLLs) as used by al=
l our binaries. By using the same compiler, end-users only need to install =
one runtime (using vcredistxxx.exe that is shipped with Visual Studio). Mov=
ing to something else (e.g. pre-compiled gzip) will break this. Also, there=
 is no recent gzip version available using Visual Studio runtime DLLs.

Please let me know your thoughts,
Regards,
Kees Dekker

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A451253NLBAWEXMBX3in_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:63920429;
	mso-list-type:hybrid;
	mso-list-template-ids:-774851292 67698703 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.25in;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.75in;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:1.25in;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:1.75in;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:2.25in;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:2.75in;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:3.25in;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:3.75in;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	margin-left:4.25in;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I tried to compile gzip with visual studio 2015. Unf=
ortunately, a few files could not be ported. Microsoft has redesigned the c=
ore CRT which affects the visibility of (hidden/internals) of e.g. the FILE=
 type. None of the internals of the
 FILE type is not visible anymore (contrary to Visual Studio 2013 and befor=
e). This affects e.g. freadingc, fpurge.c, fseeko.c, fseterr.c.<o:p></o:p><=
/p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">If something else than gcc/glibc is used, then each =
change - up to everything that the OS/libc/compiler vendor found as useful =
- may break gzip. Is it not bad programming practice to do so?<o:p></o:p></=
p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">My questions are: <o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:.25in;text-indent:-.25in=
;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">1.<span style=3D"font:=
7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>why does gzip use and rely on these internals?<o:p>=
</o:p></p>
<p class=3D"MsoListParagraph" style=3D"margin-left:.25in;text-indent:-.25in=
;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">2.<span style=3D"font:=
7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Is it intended that gzip should NOT compile on anyt=
hing else where gcc/glibc is not used?
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Background information: we are normally just compile=
 gzip to be sure that gzip uses the same bits (64-bit) and same C/C&#43;&#4=
3; runtime (DLLs) as used by all our binaries. By using the same compiler, =
end-users only need to install one runtime
 (using vcredistxxx.exe that is shipped with Visual Studio). Moving to some=
thing else (e.g. pre-compiled gzip) will break this. Also, there is no rece=
nt gzip version available using Visual Studio runtime DLLs.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Please let me know your thoughts,<o:p></o:p></p>
<p class=3D"MsoNormal">Regards,<o:p></o:p></p>
<p class=3D"MsoNormal">Kees Dekker<o:p></o:p></p>
</div>
</body>
</html>

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A451253NLBAWEXMBX3in_--




Acknowledgement sent to Kees Dekker <Kees.Dekker@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gzip@HIDDEN. Full text available.
Report forwarded to bug-gzip@HIDDEN:
bug#25633; Package gzip. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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