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

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 01 Apr 2022 06:49:02 +0000

Your bug report

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

which was filed against the gzip package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
25633: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25633
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: porting gzip to Visual Studio 2015 failed due to redesign of CRT
From: Paul Eggert <[email-masked]>
To: Kees Dekker <[email-masked]>
Cc: [email-masked]
Date: Thu, 31 Mar 2022 23:48:31 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

Subject: porting gzip to Visual Studio 2015 failed due to redesign of CRT
From: Kees Dekker <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 6 Feb 2017 15:28:08 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

Please let me know your thoughts,
Regards,
Kees Dekker