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

[Jim Meyering]

On Mon, Feb 6, 2017 at 7:28 AM, Kees Dekker <address@hidden> 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