On Mon, Feb 6, 2017 at 7:28 AM, Kees Dekker <kees.dek...@infor.com> 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
