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

From: Jim Meyering <[email-masked]>
Date: Mon, 6 Feb 2017 11:41:22 -0800

On Mon, Feb 6, 2017 at 7:28 AM, Kees Dekker <[email-masked]> wrote:
> 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 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.
>
> 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 anything 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++ 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 something else (e.g. pre-compiled gzip) will break this. Also, there 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