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
[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 i
In the eight months since gzip-1.8 there have been some bug fixes, along
with many improvements via gnulib, so here's a snapshot of the latest.
Please test it and let us know how that goes.
gzip snapshot:
http://meyering.net/gzip/gzip-ss.tar.xz 728 KB
http://meyering.net/gzip/gzip-ss.tar.
Hello,
On Mon, Feb 06, 2017 at 10:38:52AM -0800, Jim Meyering wrote:
gzip snapshot:
http://meyering.net/gzip/gzip-1.8.18-00e6.tar.xz
On Ubuntu 15/32bit, 'timestamp' fails (log attached).
On FreeBSD 11p1/amd64, 'help-version' fails (log attached).
Few other failures:
Building on Ubuntu-14.
On Mon, Feb 6, 2017 at 7: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
On Mon, Feb 06, 2017 at 10:38:52AM -0800, Jim Meyering wrote:
http://meyering.net/gzip/gzip-1.8.18-00e6.tar.xz
One more failure:
On Cygwin/2.6.0 with mingw:
===
make[2]: Entering directory '/tmp/gzip-1.8.18-00e6.bHRTJN/gzip-1.8.18-00e6'
CC version.o
AR libver.a
CC bits.o
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 a
On Mon, Feb 6, 2017 at 11:41 AM, Assaf Gordon wrote:
> On OpenBSD 6.0/5.9, these fail:
> ===
> FAIL: help-version
> ==
>
> using SHELL=/bin/sh with 'set -x' corrupts stderr
> in-44995: -15.4%
> less: unknown: unknown terminal type
> FAIL: zless
> more: unknown: unknown terminal t
On Mon, Feb 06, 2017 at 12:05:12PM -0800, Jim Meyering wrote:
On Mon, Feb 6, 2017 at 11:41 AM, Assaf Gordon wrote:
On OpenBSD 6.0/5.9, these fail:
===
FAIL: help-version
==
Can you see if this addresses the help-version failure?
-zcat_setup () { args="$args $zin"; }
+zcat_set
I reproduced the gzip timestamp bug on Fedora 25 x86-64, compiling gzip
with 'gcc -m32' to run it in 32-bit mode. The problem is partly that
gzip/test/timestamp assumes that gzip is compiled the same way that
'touch' is, and when this is not true (on my platform 'touch' is 64-bit,
but I built g
>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.
>> ...
>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
12 matches
Mail list logo