GNU bug report logs - #25633
porting gzip to Visual Studio 2015 failed due to redesign of CRT

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#25633: closed (porting gzip to Visual Studio 2015 failed due
 to redesign of CRT)
Date: Fri, 01 Apr 2022 06:49:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 31 Mar 2022 23:48:31 -0700
with message-id <10cf55d3-8db8-1d64-6084-41b5deb894da <at> cs.ucla.edu>
and subject line Re: porting gzip to Visual Studio 2015 failed due to redesign of CRT
has caused the debbugs.gnu.org bug report #25633,
regarding porting gzip to Visual Studio 2015 failed due to redesign of CRT
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
25633: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25633
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Kees Dekker <Kees.Dekker <at> infor.com>
To: "bug-gzip <at> gnu.org" <bug-gzip <at> gnu.org>
Subject: porting gzip to Visual Studio 2015 failed due to redesign of CRT
Date: Mon, 6 Feb 2017 15:28:08 +0000

[Message part 3 (text/plain, inline)]

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

[Message part 4 (text/html, inline)]

[Message part 5 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Kees Dekker <Kees.Dekker <at> infor.com>
Cc: 25633-done <at> debbugs.gnu.org
Subject: Re: porting gzip to Visual Studio 2015 failed due to redesign of CRT
Date: Thu, 31 Mar 2022 23:48:31 -0700

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.