From unknown Mon Aug 18 08:30:08 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#25633 <25633@debbugs.gnu.org> To: bug#25633 <25633@debbugs.gnu.org> Subject: Status: porting gzip to Visual Studio 2015 failed due to redesign of CRT Reply-To: bug#25633 <25633@debbugs.gnu.org> Date: Mon, 18 Aug 2025 15:30:08 +0000 retitle 25633 porting gzip to Visual Studio 2015 failed due to redesign of = CRT reassign 25633 gzip submitter 25633 Kees Dekker severity 25633 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 06 11:34:54 2017 Received: (at submit) by debbugs.gnu.org; 6 Feb 2017 16:34:54 +0000 Received: from localhost ([127.0.0.1]:57985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1camFh-0008UY-M3 for submit@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 ) id 1calDL-0006yT-Jn for submit@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 ) id 1calDF-00074x-7L for submit@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 ) id 1calDF-00074t-4z for submit@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 ) id 1calDD-0005XG-Iz for bug-gzip@gnu.org; Mon, 06 Feb 2017 10:28:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1calDA-00073n-DM for bug-gzip@gnu.org; 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 ) id 1calDA-00073C-1X for bug-gzip@gnu.org; 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 To: "bug-gzip@gnu.org" 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@NLBAWEXMBX3.infor.com> 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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

Hi,

 

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.<= /p>

 

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?

 

My questions are:

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

2.       Is it intended that gzip should NOT compile on anyt= hing else where 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+= 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.

 

Please let me know your thoughts,

Regards,

Kees Dekker

--_000_858F859BB4F2824EBAB5D4ED58214CB7016A451253NLBAWEXMBX3in_-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 06 13:05:58 2017 Received: (at 25633) by debbugs.gnu.org; 6 Feb 2017 18:05:58 +0000 Received: from localhost ([127.0.0.1]:58026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1canfq-00027g-Kb for submit@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 ) id 1canfo-00027S-O1 for 25633@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 , 25633@debbugs.gnu.org, Bug-gnulib References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Organization: Red Hat, Inc. Message-ID: <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@redhat.com> 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@NLBAWEXMBX3.infor.com> 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 To: Kees Dekker , 25633@debbugs.gnu.org, Bug-gnulib Message-ID: <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@redhat.com> Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> --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-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 06 14:41:52 2017 Received: (at 25633) by debbugs.gnu.org; 6 Feb 2017 19:41:52 +0000 Received: from localhost ([127.0.0.1]:58069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1capAd-0004H3-VQ for submit@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 ) id 1capAb-0004Gp-Hq for 25633@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@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@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> From: Jim Meyering Date: Mon, 6 Feb 2017 11:41:22 -0800 X-Google-Sender-Auth: ZaOlNc0LdyvFnbNLnFhQf4xndyc Message-ID: Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT To: Kees Dekker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 25633 Cc: 25633@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On Mon, Feb 6, 2017 at 7:28 AM, Kees Dekker 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 06 15:00:56 2017 Received: (at 25633) by debbugs.gnu.org; 6 Feb 2017 20:00:56 +0000 Received: from localhost ([127.0.0.1]:58085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1capT6-0004ik-9b for submit@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 ) id 1capT4-0004iZ-0R for 25633@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 To: bug-gnulib@gnu.org 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@linuix.haible.de> 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@redhat.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@redhat.com> 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 , 25633@debbugs.gnu.org, Kees Dekker X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 07 02:50:28 2017 Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 07:50:28 +0000 Received: from localhost ([127.0.0.1]:58283 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cb0Xj-0006AQ-Ua for submit@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 ) id 1cb0Xi-0006A9-2P for 25633@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 To: Bruno Haible , "bug-gnulib@gnu.org" 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@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@redhat.com> <2310163.ep0zRcYtDC@linuix.haible.de> In-Reply-To: <2310163.ep0zRcYtDC@linuix.haible.de> 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 , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 07 02:54:31 2017 Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 07:54:31 +0000 Received: from localhost ([127.0.0.1]:58288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cb0bf-0006GB-Kc for submit@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 ) id 1cb0bd-0006Fw-6A for 25633@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 To: Bruno Haible , "bug-gnulib@gnu.org" 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@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <3f4305f3-f387-0b75-8e37-1c1f5bffb4c2@redhat.com> <2310163.ep0zRcYtDC@linuix.haible.de> 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 , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 07 08:09:05 2017 Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 13:09:05 +0000 Received: from localhost ([127.0.0.1]:58407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cb5W5-0006pv-HM for submit@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 ) id 1cb5W3-0006pd-Hk for 25633@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 To: Kees Dekker 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@linuix.haible.de> User-Agent: KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; ) In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <2310163.ep0zRcYtDC@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@NLBAWEXMBX3.infor.com> 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 , "bug-gnulib@gnu.org" , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 07 09:14:24 2017 Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 14:14:24 +0000 Received: from localhost ([127.0.0.1]:58491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cb6XH-0008Ov-Un for submit@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 ) id 1cb6XF-0008Oi-Q0 for 25633@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 To: Bruno Haible 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@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <2310163.ep0zRcYtDC@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@NLBAWEXMBX3.infor.com> <1820635.toCcZjP9Xg@linuix.haible.de> In-Reply-To: <1820635.toCcZjP9Xg@linuix.haible.de> 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 , "bug-gnulib@gnu.org" , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 #elif HAVE_SYS_UTIME_H # include #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 = . 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
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
 
>These instructions were tested with GNU gperf and a couple of othe= r GNU
>packages. They should be applicable to GNU gzip as well.
 
This is great information. It would be nice to ship a README.windows t= ogether with the gzip sources.
Grosso modo I'm building in the way described, but put my files into V= isual Studio project.
 
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).
But still some things are incorrect:
 
  1. frexp.c is not needed, as Visual Studio already provides frexp() functi= on via system libraries.
  2. memchr.c is not needed, as Visual Studio a= lready provides memchr() function via system libraries.
  3. 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 + prototype.
  4. l= seek.c: need to include winsock2.h before including windows.h
  5. utime= ns.c: need to include sys/times.c on Windows to get struct utimbuf + ne= ed to define HAVE_STRUCT_UTIMBUF in config.h +
  6. 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.
  7. conf= ig.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: bo= th contain a xalloc_die() function. I guess this is intentionally?
    10.  
    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 inclu= ding 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_NOR= ETURN suffix. IMO unzip.c should include xalloc.h and gzip.h should not con= tain 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 nic= e 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 le= ast it starts J:
     
    gzip --version
    gzip 1.8.18-00e6
    Copyright (C) 2016 Free Software Foundati= on, Inc.
    Copyright (C) 1993 Jean-loup Gailly.
    This is free software.  You may redi= stribute 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 permi= tted by law.
     
    Written by Jean-loup Gailly.
     
    So thanks all for your help.
     
    Kees
     
     --_000_858F859BB4F2824EBAB5D4ED58214CB7016A451BCBNLBAWEXMBX3in_-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 07 09:24:42 2017 Received: (at 25633) by debbugs.gnu.org; 7 Feb 2017 14:24:42 +0000 Received: from localhost ([127.0.0.1]:58501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cb6hG-0000D6-Dy for submit@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 ) id 1cb6hD-0000Cp-41 for 25633@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 , Bruno Haible References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <2310163.ep0zRcYtDC@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@NLBAWEXMBX3.infor.com> <1820635.toCcZjP9Xg@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@NLBAWEXMBX3.infor.com> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Organization: Red Hat, Inc. Message-ID: <544a9cca-f88d-5d66-f45d-9d7f6825f64e@redhat.com> 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@NLBAWEXMBX3.infor.com> 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@gnu.org" , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 To: Kees Dekker , Bruno Haible Cc: "bug-gnulib@gnu.org" , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> Message-ID: <544a9cca-f88d-5d66-f45d-9d7f6825f64e@redhat.com> Subject: Re: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <2310163.ep0zRcYtDC@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@NLBAWEXMBX3.infor.com> <1820635.toCcZjP9Xg@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@NLBAWEXMBX3.infor.com> In-Reply-To: <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@NLBAWEXMBX3.infor.com> --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-- From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 08 11:03:20 2017 Received: (at 25633) by debbugs.gnu.org; 8 Feb 2017 16:03:20 +0000 Received: from localhost ([127.0.0.1]:60434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbUiF-0008IZ-CH for submit@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 ) id 1cbUiD-0008IJ-8Y for 25633@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 To: Bruno Haible 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@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <2310163.ep0zRcYtDC@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A4518E3@NLBAWEXMBX3.infor.com> <1820635.toCcZjP9Xg@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@NLBAWEXMBX3.infor.com> <544a9cca-f88d-5d66-f45d-9d7f6825f64e@redhat.com> In-Reply-To: <544a9cca-f88d-5d66-f45d-9d7f6825f64e@redhat.com> 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@gnu.org" , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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_-- From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 08 17:44:51 2017 Received: (at 25633) by debbugs.gnu.org; 8 Feb 2017 22:44:51 +0000 Received: from localhost ([127.0.0.1]:60609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbayp-0002OI-3M for submit@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 ) id 1cbayn-0002O8-2U for 25633@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 To: Kees Dekker 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@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <1820635.toCcZjP9Xg@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@NLBAWEXMBX3.infor.com> 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 , "bug-gnulib@gnu.org" , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 09 02:36:51 2017 Received: (at 25633) by debbugs.gnu.org; 9 Feb 2017 07:36:51 +0000 Received: from localhost ([127.0.0.1]:60756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbjHe-0007w2-82 for submit@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 ) id 1cbjHb-0007vp-KV for 25633@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 To: Bruno Haible 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@NLBAWEXMBX3.infor.com> References: <858F859BB4F2824EBAB5D4ED58214CB7016A451253@NLBAWEXMBX3.infor.com> <1820635.toCcZjP9Xg@linuix.haible.de> <858F859BB4F2824EBAB5D4ED58214CB7016A451BCB@NLBAWEXMBX3.infor.com> <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 , "bug-gnulib@gnu.org" , "25633@debbugs.gnu.org" <25633@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 01 02:48:38 2022 Received: (at 25633-done) by debbugs.gnu.org; 1 Apr 2022 06:48:38 +0000 Received: from localhost ([127.0.0.1]:40701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1naB5K-0004SU-Lr for submit@debbugs.gnu.org; Fri, 01 Apr 2022 02:48:38 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:32832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1naB5J-0004SF-Br for 25633-done@debbugs.gnu.org; Fri, 01 Apr 2022 02:48:37 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 08650160079; Thu, 31 Mar 2022 23:48:32 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id hF3ntKME5mdM; Thu, 31 Mar 2022 23:48:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 70D7E16007E; Thu, 31 Mar 2022 23:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fDKdHguB3spu; Thu, 31 Mar 2022 23:48:31 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 4CF71160079; Thu, 31 Mar 2022 23:48:31 -0700 (PDT) Message-ID: <10cf55d3-8db8-1d64-6084-41b5deb894da@cs.ucla.edu> Date: Thu, 31 Mar 2022 23:48:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Kees Dekker From: Paul Eggert Subject: Re: porting gzip to Visual Studio 2015 failed due to redesign of CRT Organization: UCLA Computer Science Department Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 25633-done Cc: 25633-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) As near as I can tell, the issues in this circa-2017 bug report were either resolved or are obsolete now so I'm closing the bug report. If I'm wrong, please feel free to file a fresh bug report. Thanks. From unknown Mon Aug 18 08:30:08 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 29 Apr 2022 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator