[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jim Meyering
Subject: bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT
Date: Mon, 6 Feb 2017 11:41:22 -0800

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:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]