GNU bug report logs -
#25633
porting gzip to Visual Studio 2015 failed due to redesign of CRT
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25633 in the body.
You can then email your comments to 25633 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Mon, 06 Feb 2017 16:35:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kees Dekker <Kees.Dekker <at> infor.com>:
New bug report received and forwarded. Copy sent to
bug-gzip <at> gnu.org.
(Mon, 06 Feb 2017 16:35:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (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 2 (text/html, inline)]
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Mon, 06 Feb 2017 18:06:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 25633 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[adding gnulib]
On 02/06/2017 09:28 AM, Kees Dekker 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?
It may be undesirable programming practice, but it beats the alternative
of not compiling at all, and is forced upon us because we WANT access to
these useful low-level details of FILE streams for optimal behavior,
even though those details are not standardized and therefore not
universally available without resorting to peeking inside the struct.
>
> My questions are:
>
> 1. why does gzip use and rely on these internals?
gzip is just using gnulib code; but gnulib does it because there are
some algorithms that really do require more information about the
current state of the FILE's buffers than what you can get through just
the standardized putc/getc interfaces.
If you can help port gnulib to the newer visual studio 2015, I'm sure
patches are welcome.
>
> 2. Is it intended that gzip should NOT compile on anything else where gcc/glibc is not used?
No; gnulib tries to make the various FILE manipulation functions
available on as many platform/compiler combinations as possible. It's
sometimes an arms race when platforms change, but we welcome patches to
catch back up to the current state of things.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Mon, 06 Feb 2017 19:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 25633 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 6, 2017 at 7:28 AM, Kees Dekker <Kees.Dekker <at> 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
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Mon, 06 Feb 2017 20:01:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 25633 <at> debbugs.gnu.org (full text, mbox):
Kees Dekker wrote:
> > 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.
gnulib has been updated to work with this platform on 2016-12-13, see
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=5506db6b006274762bf5ea1d23feb7a9801529c8
Eric Blake replied:
> If you can help port gnulib to the newer visual studio 2015, I'm sure
> patches are welcome.
> ...
> we welcome patches to catch back up to the current state of things.
While in general this is a good advise, in this case it's not needed. All
the reporter needs is a new gzip snapshot tarball that uses gnulib version
2016-12-14 or newer.
Bruno
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Tue, 07 Feb 2017 07:51:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 25633 <at> debbugs.gnu.org (full text, mbox):
>gnulib has been updated to work with this platform on 2016-12-13, see
>http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=5506db6b006274762bf5ea1d23feb7a9801529c8
>Eric Blake replied:
>> If you can help port gnulib to the newer visual studio 2015, I'm sure
>> patches are welcome.
>> ...
>> we welcome patches to catch back up to the current state of things.
>While in general this is a good advise, in this case it's not needed. All
>the reporter needs is a new gzip snapshot tarball that uses gnulib version
>2016-12-14 or newer.
Are the mentioned patches in the snapshot that was provided by Jim?
In any case, I will check today. Thanks for prompt replies.
If you like, I can share some additional changes I've made, e.g. Visual Studio does not like -g flag, a WIN32 define that should be _WIN32 (a CL.exe built-in macro), a workaround for missing #include_next directive (which is not supported by Visual Studio), a struct that is in sys/time.h instead of time.h (utimens.c). Please let me know the preferred format of changed. Is a UNIX style patch ok (using gzip-1.8.18-00e6 as reference)?
I'm not familiar enough with configure to be able to add 'auto-detect' rules for e.g. adding a HAVE_SYS_UTIME_H directive (needed in utimens.c to get struct utimbuf). The same applies to detect whether -g flag is (not) supported by the used compiler.
Background: I tried to get the Visual Studio build working by performing the following steps:
a. open a Visual Studio command prompt (that have set LIB, INCLUDE etc environment variables)
b. from within this prompt, start Cygwin shell
c. run CC=cl.exe ./configure
d. import result into a visual studio project file (this step is only needed for us to incorporate the gzip build in our own build).
Regards,
Kees
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Tue, 07 Feb 2017 07:55:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 25633 <at> debbugs.gnu.org (full text, mbox):
>Are the mentioned patches in the snapshot that was provided by Jim?
>In any case, I will check today. Thanks for prompt replies.
>If you like, I can share some additional changes I've made, e.g. Visual Studio does not like -g flag, a WIN32 define that should be _WIN32 (a CL.exe built-in macro), a workaround for missing #include_next directive (which >is not supported by Visual Studio), a struct that is in sys/time.h instead of time.h (utimens.c). Please let me know the preferred format of changed. Is a UNIX style patch ok (using gzip-1.8.18-00e6 as reference)?
>I'm not familiar enough with configure to be able to add 'auto-detect' rules for e.g. adding a HAVE_SYS_UTIME_H directive (needed in utimens.c to get struct utimbuf). The same applies to detect whether -g flag is (not) >supported by the used compiler.
Sorry, I forgot to tell one other issue (with the risk of confusing others):
Inconsistent usage in xalloc.h:56 about _Noreturn and gzip.h:325: ATTRIBUTE_NORETURN.
I would suggest to require to include xalloc.h if you need to use xalloc() or variants and not adding the same prototype in gzip.h. This requires to add xalloc.h in some places.
Visual Studio 2015 complains about different linkage if these two prototypes will be mixed.
>Background: I tried to get the Visual Studio build working by performing the following steps:
>a. open a Visual Studio command prompt (that have set LIB, INCLUDE etc environment variables)
>b. from within this prompt, start Cygwin shell
>c. run CC=cl.exe ./configure
>d. import result into a visual studio project file (this step is only needed for us to incorporate the gzip build in our own build).
Regards,
Kees
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Tue, 07 Feb 2017 13:10:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 25633 <at> debbugs.gnu.org (full text, mbox):
Hello Kees,
> If you like, I can share some additional changes I've made, e.g. Visual Studio
> does not like -g flag, a WIN32 define that should be _WIN32 (a CL.exe built-in
> macro), a workaround for missing #include_next directive (which is not
> supported by Visual Studio), a struct that is in sys/time.h instead of time.h
> (utimens.c). Please let me know the preferred format of changed. Is a UNIX
> style patch ok (using gzip-1.8.18-00e6 as reference)?
Most of these troubles should go away if you use the 'compile' and 'ar-lib'
auxiliary scripts, as described in section 2 of
http://git.savannah.gnu.org/gitweb/?p=gperf.git;a=blob_plain;f=README.windows
These instructions were tested with GNU gperf and a couple of other GNU
packages. They should be applicable to GNU gzip as well.
> Background: I tried to get the Visual Studio build working by performing the
> following steps:
> a. open a Visual Studio command prompt (that have set LIB, INCLUDE etc
> environment variables)
> b. from within this prompt, start Cygwin shell
> c. run CC=cl.exe ./configure
It is in this step 'c' that the 'compile' auxiliary script becomes useful.
Bruno
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Tue, 07 Feb 2017 14:15:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 25633 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Bruno,
>Most of these troubles should go away if you use the 'compile' and 'ar-lib'
>auxiliary scripts, as described in section 2 of
>http://git.savannah.gnu.org/gitweb/?p=gperf.git;a=blob_plain;f=README.windows
>These instructions were tested with GNU gperf and a couple of other GNU
>packages. They should be applicable to GNU gzip as well.
This is great information. It would be nice to ship a README.windows together with the gzip sources.
Grosso modo I'm building in the way described, but put my files into Visual Studio project.
Based on what I found today: the changes at low-level stdio in the FILE struct are now complable (I did not have yet a chance to let pass gzip our own internal tests, will do so later today or tomorrow).
But still some things are incorrect:
1. frexp.c is not needed, as Visual Studio already provides frexp() function via system libraries.
2. memchr.c is not needed, as Visual Studio already provides memchr() function via system libraries.
3. gzip.c/h, util.c: the strlwr() function conflicts with Visual Studio one. Added HAVE_STRLWR define in config.h and omit implementation + prototype.
4. lseek.c: need to include winsock2.h before including windows.h
5. utimens.c: need to include sys/times.c on Windows to get struct utimbuf + need to define HAVE_STRUCT_UTIMBUF in config.h +
6. unzip.c: added xalloc.h to have consistent prototype for xalloc-die() (and removed this prototype from gzip.h). See also #9 which probably explains why a prototype exists in two places? Anyhow, util.c already included xalloc.h.
7. config.h (stored in clearcase as config_win32.h): added typedefs for uid_t and gid_t.
8. tailor.h/utimes.c: HAVE_SYS_UTIME_H is defined, but not used. Should this not become part of configure and add HAVE_SYS_UTIME_H define in config.h + adjust code in utimens.c?
9. util.c/xalloc-die.c: both contain a xalloc_die() function. I guess this is intentionally?
For t#1, #2, #3, #5, #7, #8: I lack the knowledge to adjust configure in such way that correct defines in config.h are generated. Also the source code need to be adjusted (rely on system headers instead of own prototypes if there is a working 'system' counterpart. I added myself HAVE_STRLWR in config.h.
The #4 is IMO a bug. It is required to include winsock2.h before including windows.h for recent Visual Studio versions.
The same applies to #6: the prototype for xalloc_die () exists in gzip.h and xalloc.h, but differs (regarding _Neturn attribute and ATTRIBUTE_NORETURN suffix. IMO unzip.c should include xalloc.h and gzip.h should not contain a prototype for xalloc().
Regarding #8: I added a few lines in utimens.c:37:
#if HAVE_UTIME_H
# include <utime.h>
#elif HAVE_SYS_UTIME_H
# include <sys/utime.h>
#endif
On Windows/Visual Studio sys/utime.h defines struct utimebuf (so HAVE_STRUCT_UTIMBUF need to be defines as well in config.h). But it would be nice if configure detects this.
>It is in this step 'c' that the 'compile' auxiliary script becomes useful.
Finaly I've a gzip.exe using native Visual Stduio libraries. And at least it starts :):
gzip --version
gzip 1.8.18-00e6
Copyright (C) 2016 Free Software Foundation, Inc.
Copyright (C) 1993 Jean-loup Gailly.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.
Written by Jean-loup Gailly.
So thanks all for your help.
Kees
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Tue, 07 Feb 2017 14:25:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 25633 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 02/07/2017 08:13 AM, Kees Dekker wrote:
> Based on what I found today: the changes at low-level stdio in the FILE struct are now complable (I did not have yet a chance to let pass gzip our own internal tests, will do so later today or tomorrow).
> But still some things are incorrect:
>
> 1. frexp.c is not needed, as Visual Studio already provides frexp() function via system libraries.
But probably with bugs. And even if it is not needed on your platform,
it is part of the tarball to replace broken frexp() on systems where it
is buggy. Part of configure determines if it is needed on your platform.
> 2. memchr.c is not needed, as Visual Studio already provides memchr() function via system libraries.
Likewise.
> 3. gzip.c/h, util.c: the strlwr() function conflicts with Visual Studio one. Added HAVE_STRLWR define in config.h and omit implementation + prototype.
> 4. lseek.c: need to include winsock2.h before including windows.h
> 5. utimens.c: need to include sys/times.c on Windows to get struct utimbuf + need to define HAVE_STRUCT_UTIMBUF in config.h +
> 6. unzip.c: added xalloc.h to have consistent prototype for xalloc-die() (and removed this prototype from gzip.h). See also #9 which probably explains why a prototype exists in two places? Anyhow, util.c already included xalloc.h.
> 7. config.h (stored in clearcase as config_win32.h): added typedefs for uid_t and gid_t.
> 8. tailor.h/utimes.c: HAVE_SYS_UTIME_H is defined, but not used. Should this not become part of configure and add HAVE_SYS_UTIME_H define in config.h + adjust code in utimens.c?
> 9. util.c/xalloc-die.c: both contain a xalloc_die() function. I guess this is intentionally?
>
> For t#1, #2, #3, #5, #7, #8: I lack the knowledge to adjust configure in such way that correct defines in config.h are generated. Also the source code need to be adjusted (rely on system headers instead of own prototypes if there is a working 'system' counterpart. I added myself HAVE_STRLWR in config.h.
I'm less certain on the solutions for the others, although patches to
gnulib are welcome.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Wed, 08 Feb 2017 16:04:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 25633 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> 1. frexp.c is not needed, as Visual Studio already provides frexp() function via system libraries.
>But probably with bugs. And even if it is not needed on your platform,
>it is part of the tarball to replace broken frexp() on systems where it
>is buggy. Part of configure determines if it is needed on your platform.
Possibly, but why is the chance on bugs on Microsoft's frexp() higher? The only (unfortunately common) practice of Microsoft is that they may differ from 'standard' behavior on Linux.
>I'm less certain on the solutions for the others, although patches to
>gnulib are welcome.
I'm not sure whether I've the knowledge to do so, but today I tried to get gdiff also compilable in Cygwin shell (with all required environment variables used by Visual Studio's cl.exe properly set) + CC=cl.exe ./configure
And funny enough, I'm recognizing things. Gdiff also uses gnulib. A piece of the output is:
checking absolute name of <wchar.h>... ""
So if a system header is not found, it expands to an empty string. Because Microsoft Visual Studio does not recognize the include_next pragma, I used the following trick:
The #include[_next] "" directive was replaced by #include "../ucrt/headerfile". This works well for the Windows 10 SDK. If an older Visual Studion version is used, use #include "../include/headerfile", where <headerfile> can be replaced by any system header (e.g. wchar.h or sys/types.h).
What is the recommended to get this behavior changed? It requires changes in configure to detect whether a ‘dotdot’ construct works for visual studio (and only of compiler matches with cl[.exe]) and if the header indeed exists (Windows has e.g. no dirent.h and much other UNIX style headers).
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Wed, 08 Feb 2017 22:45:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 25633 <at> debbugs.gnu.org (full text, mbox):
Hi Kees,
> 1. frexp.c is not needed, as Visual Studio already provides frexp() function via system libraries.
The configure log says:
checking whether frexp works... guessing no
...
checking whether frexpl works... guessing no
Why "guessing"? Apparently AC_RUN_IFELSE refuses to run the
test program when compiling to mingw on a Cygwin host. Argh.
But it's documented in doc/posix-functions/frexp.texi
https://www.gnu.org/software/gnulib/manual/html_node/frexp.html
Do you have data that shows that MSVC14's frexp() behaves better than
the one in MSVC 9?
> 2. memchr.c is not needed, as Visual Studio already provides memchr() function via system libraries.
The configure log says:
checking whether memchr works... guessing no
Again the AC_RUN_IFELSE problem.
> 3. gzip.c/h, util.c: the strlwr() function conflicts with Visual Studio one. Added HAVE_STRLWR define in config.h and omit implementation + prototype.
That makes you depend on what Microsoft happens to implement in its
library. https://msdn.microsoft.com/en-us/library/ms235455.aspx
> 4. lseek.c: need to include winsock2.h before including windows.h
I'm not observing this problem with building this gzip snapshot.
> 5. utimens.c: need to include sys/times.c on Windows to get struct utimbuf + need to define HAVE_STRUCT_UTIMBUF in config.h +
Likewise: I'm not observing this problem.
> 7. config.h (stored in clearcase as config_win32.h): added typedefs for uid_t and gid_t.
config.h is autogenerated with my README.windows instructions.
> 9. util.c/xalloc-die.c: both contain a xalloc_die() function. I guess this is intentionally?
The one in util.c is meant to override the one from gnulib. This is normally
achieved by having the gnulib code linked as a library.
My build attempt aborted like this:
C:\cygwin64\home\bruno\gzip-1.8.18-00e6\gzip.c(1900): error C2146: syntax error: missing ')' before identifier 'uid'
C:\cygwin64\home\bruno\gzip-1.8.18-00e6\gzip.c(1900): error C2081: 'uid_t': name in formal parameter list illegal
C:\cygwin64\home\bruno\gzip-1.8.18-00e6\gzip.c(1900): error C2061: syntax error: identifier 'uid'
Indeed all uses of uid_t and gid_t need to be revisited when porting to native Windows.
Bruno
Information forwarded
to
bug-gzip <at> gnu.org:
bug#25633; Package
gzip.
(Thu, 09 Feb 2017 07:37:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 25633 <at> debbugs.gnu.org (full text, mbox):
Hi Bruno,
Thanks for reply.
>> 1. frexp.c is not needed, as Visual Studio already provides frexp() function via system libraries.
...
>Do you have data that shows that MSVC14's frexp() behaves better than the one in MSVC 9?
Do you have advice how I can check this quickly? Visual Studio 2015 is VC14, so may be 5 versions ahead, something may be fixed? If you have a test code, I will check for you.
>> 4. lseek.c: need to include winsock2.h before including windows.h
>I'm not observing this problem with building this gzip snapshot.
I have used configure to let it generate the required headers, but finally, all was imported in a visual studio project, so my final compile is using visual studio itself (and therefore may be using slightly different defaults, as I use some base property sheets to globally define some settings, e.g. whole program optimization for optimized builds and some other defines and settings).
>> 5. utimens.c: need to include sys/times.c on Windows to get struct utimbuf + need to define HAVE_STRUCT_UTIMBUF in config.h +
>Likewise: I'm not observing this problem.
Probably same cause, due to my native visual studio compilation.
>> 7. config.h (stored in clearcase as config_win32.h): added typedefs for uid_t and gid_t.
>config.h is autogenerated with my README.windows instructions.
There is no README.windows file in the tar.gz file of the gzip sources, so it would be very handy to add it there. This email chain told me that there is something like README.windows for gnulib....
>> 9. util.c/xalloc-die.c: both contain a xalloc_die() function. I guess this is intentionally?
>The one in util.c is meant to override the one from gnulib. This is normally achieved by having the gnulib code linked as a library.
But it IMO still strange to have two different prototypes for a similar function (that got implemented in two places). If these are harmonized, then there is no problem. The order of including header files may now conflict with the implementation that comes first...
Kees
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Fri, 01 Apr 2022 06:49:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Kees Dekker <Kees.Dekker <at> infor.com>:
bug acknowledged by developer.
(Fri, 01 Apr 2022 06:49:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 25633-done <at> debbugs.gnu.org (full text, mbox):
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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 29 Apr 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 63 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.