Zopfli is non-deterministic about zopfli HOT 8 OPEN

This is not supposed to happen. Which zopfli settings did you use? Are the 
output files correct (decompress to the original file without error) in both 
cases? Which compiler did you use on each platform? Thanks.

The Ubuntu box is a Travis CI VM. You can check the logs here: 
https://travis-ci.org/mathiasbynens/grunt-zopfli/jobs/7485621#L291

As you can see, to install Zopfli v1.0.0 I use the following commands:

    curl -O "https://zopfli.googlecode.com/files/zopfli-1.0.0.zip"
    unzip zopfli-1.0.0.zip; cd zopfli-1.0.0
    make
    chmod +x zopfli
    export PATH="$(pwd):${PATH}"
    cd ..

`make` results in the following:

    gcc src/zopfli/*.c -O2 -W -Wall -Wextra -ansi -pedantic -lm -o zopfli

I’ve compiled Zopfli v1.0.0 with exactly this same command on my OS X box but 
I’m still getting different results compared to the Travis CI VM (which is 
causing my project’s tests to fail).

The Zopfli settings vary for each one of the tests, but on both machines the 
same settings are being used for each test. The settings are hardcoded here: 
https://github.com/mathiasbynens/grunt-zopfli/blob/f4ea75338876d15b0f6051114bd96
8bb861e2cd6/Gruntfile.js#L11-L65

Here’s another log where I tried to compare the MD5 hashes of the expected 
resulting files with the actual result. On my OS X box the files are identical, 
but on the Ubuntu box, the files generated by Zopfli differ from the expected 
output. https://travis-ci.org/mathiasbynens/grunt-zopfli/jobs/7815241#L342

I’m stumped.

[deleted comment]

I forgot to mention, the generated files on my OS X box decompress just fine.

Is there an easy way to test Zopfli’s output when the `deflate` or `zlib` 
output formats are used, i.e. to decompress Zopfli’s `deflate`/`zlib` output?

Re: #5: Got it: to decompress `zlib`: use inflate; to decompress `deflate`: use 
raw inflate (no header).

I noticed this too.
I write a program to compress png using zopflipng library. I compiled it using 
vs2013 and mingw.
For 99% of the png files I tested, the two results are the same, but I found a 
png that if compressed with vs2013 build, the result will be 5 bytes smaller 
than mingw every time.

Options I use:
    ZopfliPNGOptions zopflipng_options;
    zopflipng_options.lossy_transparent = true;
    zopflipng_options.block_split_strategy = 3;
all other options are default.

The best possible explanation so far is that the double floating point 
arithmetic works slightly different on each...