fhanau / efficient-compression-tool Goto Github PK

Example image: https://i.imgur.com/9n5XaOe.png

Commandline (using 5f962a0): ECT.exe -7 --allfilters --mt-deflate --strict image.png

Image becomes mostly black with some pixels of seemingly random color. Rarely the image is optimized correctly.

Compiled with GCC 5.3.0 on Windows 7 x64 with Boost support and -march=native -mtune=native. Running on a Haswell-E i7-5820k, a 6-core hyperthreaded CPU.

Seems to be caused by the improvement to filtering, I think. Does not occur in ad36d79 even with same compile switches/commandline and compiling today.

I get ECT.exe stopped working on Windows 10 build 16232.170624-1334.

I've noticed you're using Cloudflare's zlib, just wondering if you've tried libdeflate? Not sure how it compares but I've read some indications that it could be faster/better.

Currently, attempting to optimize a file such as 「」.jpg gives error No compatible files found. Don't know if it works on Linux/OS X.

is it possible to avoid re compressing already compressed files, dose that happen automatically or there is a flag for that somehow

i want the app to only compress uncompressed files when running the command multiple times to the same target folder or files .. is that possible?

I won't claim to know much about multithreading but I think there are two possible ways it could be improved in ect.

1. Thread pooling
2. Per-file threading

I'd interested in looking into it myself, I have heard of OpenMP, though it may be a wee bit out of my depth...

When optimized ZIP based files, such as DOCX, it is required to add the -zip modifier. If not, ECT will not be able to recognize it, and report. "No compatible files found".

Then, if I add the -zip, something like this:
D:\SVN\FileOptimizer.\Win64\Debug\Plugins64\ECT.exe -quiet -zip --mt-deflate -s -5 "C:\Users\JGUTIE~1\AppData\Local\Temp\FileOptimizer_Input_4277_copia.docx"

The resulting optimized file, will not be FileOptimizer_Input_4277_copia.docx as expected, but FileOptimizer_Input_4277_copia.docx.zip, with an extra .zip added at the end.

This tool looks really great.

Is there a place to download up-to-date Mac and Windows binaries?

Thanks!

I've tried to compile with ArchLinux. Just used make / make install. Dependencies and nasm are present, compiler: gcc 6.2.1

With libjpeg-turbo, but without mozjpeg, it just fails
make[3]: Verzeichnis „../Efficient-Compression-Tool-0.6.1/src/mozjpeg“ wird verlassen

With mozjpeg, the following compilation error happens:

g++ -Ofast -std=gnu++11 main.cpp blocksplitter.o codec.o image.o lz77.o opngreduc.o squeeze.o util.o LzFind.o support.cpp zopflipng.cpp zopfli/deflate.cpp zopfli/zopfli_gzip.cpp zopfli/katajainen.cpp lodepng/lodepng.cpp lodepng/lodepng_util.cpp optipng/optipng.cpp jpegtran.cpp gztools.cpp mozjpeg/.libs/libjpeg.a libpng/libpng.a zlib/libz.a -o ../ECT
/tmp/ccu3X25P.o: In function `DeflateSplittingFirst2(ZopfliOptions const*, int, unsigned char const*, unsigned long, unsigned long, unsigned char*, unsigned char**, unsigned long*, unsigned int, unsigned char, ZopfliLZ77Store*)':
deflate.cpp:(.text+0x502e): undefined reference to `pthread_create'

i can't replicate this bug with anything other than this exact zip file (i was trying to fix and recompress a Doom mod froom 10 years ago, this is just the changed files)
no matter what arguments i use, it corrupts the header of models/cube/marbox.png
i've tried it with both v0.8.2 and b89e55f

When ect stop running with error, we can not understand which file is a reason of stop.
For example, just now I received the error:

Corrupt JPEG data: premature end of data segment
Unsupported marker type 0x11

But how I can understand which file is guilty for error to exclude it from collection?
(I know I can process each file separately in shell cycle, but that make -recursive key is useless)

p.s. and will be nice to have some option to ignore file with error and keep processing other files.

ECT ~2 times slower than Leanify on same jpeg files with same final result.
As I can see ECT and Leanify both use mozjpeg module (or maybe even ECT use Leanify, I don't know)

But ECT process jpeg-files 2-2.5 times slower with binary same result.

For comparison I used binary compiled blobs from FileOptimizer 9.8 package on Windows 10 x64 (intel i3-7100, HT on, ssd)
ECT 0.7
Leanify 0.4.3

Some guys got same result: https://goo.gl/hXejg9

May be it is problem at this specific binaries, idk. But .png processing look nice (ECT 2-2.5 times faster)

I'm running ECT with Windows 10 which works perfectly fine. On Windows Vista i've had some problems sometimes "ECT has stopped working" on some pngs. Those same pngs are optimized without any issues on Windows 10. How to help to fix this? I found the executables on a forum, i can't tell they're good or not. Thank you for your consideration.

I get the following libtool error when compiling v0.8.2 on ArchLinux.

Making all in simd
make[3]: Entering directory '/home/bluephoenix47/workspace/aur4/ect/src/ect/src/mozjpeg/simd'
  GEN      jsimdcfg.inc
make  all-am
make[4]: Entering directory '/home/bluephoenix47/workspace/aur4/ect/src/ect/src/mozjpeg/simd'
  CC       libsimd_la-jsimd_x86_64.lo
libtool: Version mismatch error.  This is libtool 2.4.6, but the
libtool: definition of this LT_INIT comes from libtool 2.4.6.40-6ca5-dirty.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6
libtool: and run autoconf again.
make[4]: *** [Makefile:706: libsimd_la-jsimd_x86_64.lo] Error 63
make[4]: Leaving directory '/home/bluephoenix47/workspace/aur4/ect/src/ect/src/mozjpeg/simd'
make[3]: *** [Makefile:472: all] Error 2

The problem appears to be a result of generated autoconf files being included in the repository, and a difference between the libtool versions on my machine and the dev machine. I can work around the issue by running autoreconf -i in the mozjpeg directory, then compiling.

Testing compiles of dc1033a vs 83a1fd9 shows that at least for me dc1033a is much slower.

Using GCC 5.3.0 msys2 to compile on Windows 7 x64 with "-flto -march=native -mtune=native" added to C(XX)FLAGS on an AVX2-capable Intel CPU, the resulting binary of dc1033a is approx 2-3x slower than 83a1fd9. I am testing on large (7MB, ~8 megapixel) 24-bit PNGs.

Using commandline ect -9 --strict --mt-deflate=12 image.png. Hopefully can be fixed.

Thanks for making ECT.

Thank you very much for Efficient-Compression-Tool !! Have you think for lossy switch for PNG and JPG? It will be very nice if you add this to this great optimiser !! Thanks again

Hi,

I try to compile v0.7 on Debian Jessie.

# gcc --version
gcc (Debian 4.9.2-10) 4.9.2

The compilation fails with the following messages:

cd src
make
.
.
.
gcc -c -Ofast -std=gnu11 optipng/codec.c optipng/image.c zopfli//util.c zopfli/squeeze.c zopfli/lz77.c \
zopfli/blocksplitter.c optipng/opngreduc/opngreduc.c LzFind.c miniz/miniz.c
g++ -pthread -Ofast -std=gnu++11 main.cpp blocksplitter.o codec.o image.o lz77.o opngreduc.o squeeze.o util.o LzFind.o miniz.o support.cpp zopflipng.cpp zopfli/deflate.cpp zopfli/zopfli_gzip.cpp zopfli/katajainen.cpp lodepng/lodepng.cpp lodepng/lodepng_util.cpp optipng/optipng.cpp jpegtran.cpp gztools.cpp leanify/zip.cpp leanify/leanify.cpp mozjpeg/.libs/libjpeg.a libpng/libpng.a zlib/libz.a -o ../ECT
leanify/zip.cpp: In function ‘bool {anonymous}::GetCDHeaders(const uint8_t*, size_t, const {anonymous}::EOCD&, size_t, std::vector<{anonymous}::CDHeader>*, size_t*)’:
leanify/zip.cpp:112:3: error: ‘sort’ is not a member of ‘std’
   std::sort(cd_headers.begin(), cd_headers.end(),
   ^
leanify/zip.cpp: In member function ‘uint32_t Zip::RecompressFile(unsigned char*, uint32_t, uint32_t, std::string, const ECTOptions&)’:
leanify/zip.cpp:142:14: warning: ‘char* getwd(char*)’ is deprecated (declared at /usr/include/unistd.h:525) [-Wdeprecated-declarations]
   char* t0 = getwd(0);
              ^
leanify/zip.cpp:142:21: warning: ‘char* getwd(char*)’ is deprecated (declared at /usr/include/unistd.h:525) [-Wdeprecated-declarations]
   char* t0 = getwd(0);
                     ^
leanify/zip.cpp: In member function ‘size_t Zip::Leanify(const ECTOptions&, long unsigned int*)’:
leanify/zip.cpp:167:33: error: ‘search’ is not a member of ‘std’
   uint8_t* first_local_header = std::search(fp_, fp_ + size_, header_magic, std::end(header_magic));
                                 ^
leanify/zip.cpp:189:14: error: ‘find_end’ is not a member of ‘std’
     p_eocd = std::find_end(p_searchstart, p_end, eocd.magic, std::end(eocd.magic));
              ^
Makefile:15: recipe for target 'bin' failed
make: *** [bin] Error 1

I also have clang installed on the system:

# clang --version
Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

Could you please give me some instructions on how to try to compile the program with clang instead of gcc ? Thanks!

Hello!
I wanted to ask you, to release the PNGwolf version with support of your zopfli version.

Would gif compression be coming and how difficult would this be?

Feature request: Add an option to keep file modification date&time.

Reason: For some files (e.g. .png) no other way to store create/modification time than in file attributes (when change the file name is undesirably).

Effect is: Make lossless optimization real lossless: keep important file information on the place.

Assumes char is signed, but on some archs such as ARM char is unsigned.

Example:

$ ect -q --allfilters-b somefile.png
warning: You have decided to enable genetic filtering, which may take a very long time.
the current generation and number of bytes is displayed.
you can stop the genetic filtering anytime by pressing ctrl-c
it will automatically stop after 500 generations without progress
Generation 0: 69461 bytes
Generation 1: 69456 bytes
Generation 3: 69419 bytes
Generation 5: 69145 bytes
...

Let image directory has such files:

1_jpeg_file.jpg
2_png_file.png
3_jpg_file.jpg
4_png_file.jpg    <- here wrong extension
5_jpg_file.jpg
6_jpg_file.jpg

When I run
ect directory/*
1,2,3 file will be processed, on 4 file ect will brake with message:
4_png_file.jpg: Not a JPEG file: starts with 0x89 0x50

And here not very good 2 things:

• no show statistic about processed files
• other files (5,6,...) will not be processed too.

I understand, renaming files it's not job of ECT, but not fail batch process please.

I tried this tool on two images, a small palettized PNG and a large full-color PNG. Both had already been pretty well-compressed with other tools. As this was my first time using this optimizer, I made copies of the files and then stepped through the various settings to see what would happen. I used --strict -M# on both files.

Starting with the small file, -M1 made no changes, as I expected. -M2, however, unexpectedly produced a large reduction of almost 42% (61.5 KB removed). -M3 through -M5 then made no further changes, all saying "ECT: error: bad adaptive filter value". In addition, -M5 reported, "Decoding error 58: invalid ADLER32 encountered (checking ADLER32 can be disabled)". I opened the file in an image viewer to discover that the lines of the image looked like they had been scrambled, while the colors and large-scale order mostly seemed to be intact.

I tried again with a fresh copy of the small image, going immediately to --strict -M5, which produced exactly the same results. With another fresh copy, I tried removing the --strict flag, but this again produced the same results.

Thinking that perhaps ECT had a bug with its support for palettized images, I tried again with a larger, full-color PNG. Again, --strict -M1 made no changes and -M2 produced a large reduction of 31.6% (468 KB). Opening the file immediately, I saw that it was mostly black with bright R/G/B/C/M/Y/W pixels corresponding to edges of objects and gradients in the original image.

So, rather than failing on a certain type of PNG, it looks like there is some more general failure with reading or writing proper PNG files. Since this immediately corrupts the source image with no notification, I'd suggest trying to fix this quickly.

See attached for the images I was working with.

Thanks,
Aaron

Windows 7 SP1

Hi Felix,

Can you please adjust your Boost implementation to properly support Windows paths?

main.cpp: In function 'int main(int, const char**)':
main.cpp:353:104: error: cannot convert 'const value_type* {aka const wchar_t*}' to 'const char*' for argument '1' to 'void PerFileWrapper(const char*, const ECTOptions&)'
                     for(unsigned i = 0; i < paths.size(); i++){PerFileWrapper(paths[i].c_str(), Options);}
                                                                                                        ^
main.cpp:359:65: error: cannot convert 'const value_type* {aka const wchar_t*}' to 'const char*' for argument '1' to 'void PerFileWrapper(const char*, const ECTOptions&)'
                         PerFileWrapper(paths[i].c_str(), Options);}
                                                                 ^

As defined by Boost:

  class BOOST_FILESYSTEM_DECL path
  {
  public:

    //  value_type is the character type used by the operating system API to
    //  represent paths.

# ifdef BOOST_WINDOWS_API
    typedef wchar_t                        value_type;
    BOOST_STATIC_CONSTEXPR value_type      preferred_separator = L'\\';
# else 
    typedef char                           value_type;
    BOOST_STATIC_CONSTEXPR value_type      preferred_separator = '/';
# endif
    typedef std::basic_string<value_type>  string_type;  
    typedef std::codecvt<wchar_t, char,
                         std::mbstate_t>   codecvt_type;

Boost also defines functions for wchar conversion in the boost::filesystem::path_traits namespace that you can use for this. Thanks!

For zip archives that have been created using level 0 ("store"), ect does not recompress the files inside.

hi felix,
first congrats for ect, it's probably the fastest zlib/zopfli implementations i've tested. i have a small suggestion for --reuse. it currently keeps the same color type and filter but perhaps you should consider that some tools are sorting colors in palette in some ways to use filtering. in this case, keeping the initial ordering will be better. can you add this to your tool?
greetings.

See https://encode.ru/threads/2274-ECT-an-file-optimizer-with-fast-zopfli-like-deflate-compression?p=56584&viewfull=1#post56584

Currently ect sends all of its output to stdout, including error messages, e.g.

$ ect doesnotexist.png 2>/dev/null 
doesnotexist.png: bad file
No compatible files found

It would be nice if it sent error messages to `stderr following the common convention in unix.

I am posting here the issue detected with FileOptimizer (https://sourceforge.net/p/nikkhokkho/discussion/fileoptimizer/thread/22104b78/?limit=25#c316) when recompressing DOCX with attached images such as the attached sample.

Command-line used was:
test.docx
ECT.exe -quiet --mt-deflate -zip -strip -9 "C:\Users\javie\AppData\Local\Temp
test.docx
test.docx"

Running latest version of ect on Ubuntu 16.04 64-bit, it's segfaulting on jpegs larger than 512x512. Fiddling with the options didn't help.

jar files are "just" zip files, so I figured they ought to work. However, a quick experiment with the JabRef jar yielded the following error:

> ect -9 -zip --strict --mt-deflate /tmp/JabRef-4.2.jar
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid
fish: “ect -9 -zip --strict --mt-defla…” terminated by signal SIGABRT (Abort)

Some version info:

Efficient Compression Tool
(c) 2014-2016 Felix Hanau.
Version 0.8.2 compiled on Jul  4 2018
Folder support disabled
Losslessly optimizes GZIP, ZIP, JPEG and PNG images

Can you build ECT 0.2 for Win32 plattforms too?
Thanks.

Would it be possible to automatic jpeg rotation according to the orientation set in the exif?
Test image: http://fredericiana.com/media/2013/monalisa.jpg

Is it possible to swap out mozjpeg for https://github.com/google/guetzli/

build aborts with:
make -C libpng/ -f scripts/makefile.gcc CC="gcc" CFLAGS="-Ofast -std=gnu11 -fsigned-char -DPNG_USER_CONFIG -Wno-macro-redefined" libpng.a
make[1]: Entering directory /tmp/Efficient-Compression-Tool-0.8.2/src/libpng' make[1]: scripts/makefile.gcc: No such file or directory make[1]: *** No rule to make target scripts/makefile.gcc'. Stop.
make[1]: Leaving directory `/tmp/Efficient-Compression-Tool-0.8.2/src/libpng'
make: *** [libpng] Error 2

platform: ubuntu 14.04.5 lts, gcc-6.3

best regards

Please add support for ZIP files as input
(recompress stored/deflated files or copy from original archive if smaller)

Previous versions compiled fine. The latest release gives me this error:

...
cp pngusr.h libpng/pngusr.h
make -C libpng/ -f scripts/makefile.gcc CC="gcc" CFLAGS="-Ofast -std=gnu11 -msse4.2 -mpclmul -DPNG_USER_CONFIG -Wno-macro-redefined" libpng.a
make[1]: Entering directory '/home/user/dists/Efficient-Compression-Tool-0.8/src/libpng'
make[1]: scripts/makefile.gcc: No such file or directory
make[1]: *** No rule to make target 'scripts/makefile.gcc'.  Stop.
make[1]: Leaving directory '/home/user/dists/Efficient-Compression-Tool-0.8/src/libpng'
Makefile:33: recipe for target 'libpng' failed
make: *** [libpng] Error 2

Checking the contents of directory src/libpng :

# ls -alsh Efficient-Compression-Tool-0.8/src/libpng
total 12K
4.0K drwxrwxr-x  2 root root 4.0K Jun 25 20:08 .
4.0K drwxrwxr-x 10 root root 4.0K Jun 25 16:29 ..
4.0K -rw-r--r--  1 root root 3.2K Jun 25 20:08 pngusr.h

There is only one file??!

gcc version is:

# gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

As per the author of FileOptimizer I submit a ticket.

I've tried to cover as much ground as possible so here goes.

FileOptimizer version : 8.30.1456
System : Windows 7 Pro, french. SP1. 64 bits. Latest patches.
AMD Phenom II X6 1100T Thuban 45nm on an ASUSTeK Computer INC. M5A87 (AM3R2)
12gig Ram DDR 3
1024 Mb ATI AMD Radeon HD 5700 Series
System very stable.

When running FileOptimizer (64 bits) to compress .PNG files, I always get an error message as soon as FO calls ECT. I've also been able to reproduce the error by starting ECT via the command line with admin privileges.

Message is "ECT has ceased functioning".

I've tried both small (<512 bytes) and large (> 5mb) picture files.

ECT seems to work properly if run in 32 bit mode (tried a few files via command line and -9 as an argument)

In 64 bit mode, If I start ECT with no arguments, it gives me instructions on the command line. So there is no corruption in the executable (or is there).

OTHER OBSERVATIONS
I have a windows XP virtual machine. ECT works fine in the virtual machine (works in 32 bits obviously)
Folder / file names contain no strange or illegal characters.
Crashes from the command line in Windows7 as it does with FileOptimizer 64 bits.
Using Microsoft Security Essentials as an anti-virus. Does not flag the file.
UAC disabled.
Files are not read-only or open in another application.

Here's what Windows has to say :
Source : Application Error
ID de l’événement :1000
Catégorie de la tâche :(100)
Niveau : Erreur
Mots clés : Classique
Utilisateur : N/A
Nom de l’application défaillante ECT.exe, version : 0.0.0.0, horodatage : 0x56ba7d3a
Nom du module défaillant : ECT.exe, version : 0.0.0.0, horodatage : 0x56ba7d3a
Code d’exception : 0xc000001d
Décalage d’erreur : 0x00000000000288fe
ID du processus défaillant : 0x2094
Heure de début de l’application défaillante : 0x01d1a47b1cca156d
ID de rapport : 5a8e9521-106e-11e6-8fea-bcaec56f76e0

If you need any further information or testing on my part, I am available.

Thank you!

Optimizing any DOCX document, causes ECT 0.8.2 to crash.

Find attached sample:
readme.docx

Used command-line was:
D:\PROYECTOS\FileOptimizer\Win32\Release\Plugins64\ECT.exe -quiet -zip --mt-deflate -s -9 "C:\Users\javie\AppData\Local\Temp\FileOptimizer_Input_7769_readme.docx"

Hello!
I have noticed strange behavior of ECT.

File: 8200 PNG

Algorithm ect -4 (new):

for %%i in (PNG\*) do (
    ect -4 "%%i"
    krzydefc --gzipname "%%i"
    ect -4 -gzip "%%i.gz"
    krzydefc --png"%%~i" "%%i.gz"
    del "%%i.gz"
    move /y "%%i.gz.png" "%%i"
)

Explain, please, why so occurs?

Can't back up the output file .. i see this message appears sometimes, what dose it mean?

macOS 10.13, quad-core i7.
"Bus error: 10" when using ect -zip --mt-deflate to compress (or recompress) certain large files, such as binaries.

main.cpp:391:20: error: ‘UINT_MAX’ was not declared in this scope
             if(f > UINT_MAX){

Maybe need to include "limits.h"?
I don't know how it compiling without it.

P.S. ECT is great!

squeeze.c line 1088:
if (options->ultra != 3) { break; }
this comparison is always true. because options->ultra==2 in line 1055.
so this loop can't pass over one time.

Ive been using ECT with FileOptimizer. ECT keeps crashing. like maybe one in every 100-200 files it crashes.

Im on Windows XP, latest patches and such. I would be happy to help in providing you with anything else you need to fix the error.

hi Felix,

why did you use this transformation only for zopflipng? you should get better results if you add this with the optipng process too, instead of turning rgb values to 0,0,0.

greetings.

checking for nasm... nasm
checking for object file format of host system... Mach-O64
checking for object file format specifier (NAFLAGS) ... -fmacho64 -DMACHO -D__x86_64__
checking whether the assembler (nasm -fmacho64 -DMACHO -D__x86_64__) works... no
configure: error: installation or configuration problem: assembler cannot create object files.
make[1]: *** No targets specified and no makefile found. Stop.
make: *** [mozjpeg] Error 2

Use getcwd instead of getwd:

leanify/zip.cpp: In member function ‘uint32_t Zip::RecompressFile(unsigned char*, uint32_t, uint32_t, std::__cxx11::string, const ECTOptions&)’:
leanify/zip.cpp:188:14: warning: ‘char* getwd(char*)’ is deprecated [-Wdeprecated-declarations]
   char* t0 = getwd(0);
              ^
In file included from /usr/include/features.h:367:0,
                 from /usr/include/x86_64-linux-gnu/c++/5/bits/os_defines.h:39,
                 from /usr/include/x86_64-linux-gnu/c++/5/bits/c++config.h:482,
                 from /usr/include/c++/5/cstdio:41,
                 from leanify/../main.h:9,
                 from leanify/zip.h:4,
                 from leanify/zip.cpp:1:
/usr/include/x86_64-linux-gnu/bits/unistd.h:221:1: note: declared here
 __NTH (getwd (char *__buf))
 ^
leanify/zip.cpp:188:14: warning: ‘char* getwd(char*)’ is deprecated [-Wdeprecated-declarations]
   char* t0 = getwd(0);
              ^
In file included from /usr/include/features.h:367:0,
                 from /usr/include/x86_64-linux-gnu/c++/5/bits/os_defines.h:39,
                 from /usr/include/x86_64-linux-gnu/c++/5/bits/c++config.h:482,
                 from /usr/include/c++/5/cstdio:41,
                 from leanify/../main.h:9,
                 from leanify/zip.h:4,
                 from leanify/zip.cpp:1:
/usr/include/x86_64-linux-gnu/bits/unistd.h:221:1: note: declared here
 __NTH (getwd (char *__buf))
 ^
leanify/zip.cpp:188:21: warning: null argument where non-null required (argument 1) [-Wnonnull]
   char* t0 = getwd(0);
                     ^
leanify/zip.cpp:188:21: warning: ‘char* getwd(char*)’ is deprecated [-Wdeprecated-declarations]
In file included from /usr/include/features.h:367:0,
                 from /usr/include/x86_64-linux-gnu/c++/5/bits/os_defines.h:39,
                 from /usr/include/x86_64-linux-gnu/c++/5/bits/c++config.h:482,
                 from /usr/include/c++/5/cstdio:41,
                 from leanify/../main.h:9,
                 from leanify/zip.h:4,
                 from leanify/zip.cpp:1:
/usr/include/x86_64-linux-gnu/bits/unistd.h:221:1: note: declared here
 __NTH (getwd (char *__buf))
 ^
leanify/zip.cpp:212:54: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result [-Wunused-result]
     fread(data - size_leanified, 1, new_size, stream);
                                                      ^
In file included from /usr/include/unistd.h:1151:0,
                 from leanify/zip.cpp:7:
In function ‘char* getwd(char*)’,
    inlined from ‘uint32_t Zip::RecompressFile(unsigned char*, uint32_t, uint32_t, std::__cxx11::string, const ECTOptions&)’ at leanify/zip.cpp:188:21:
/usr/include/x86_64-linux-gnu/bits/unistd.h:225:29: warning: call to ‘__getwd_warn’ declared with attribute warning: please use getcwd instead, as getwd doesn't specify buffer size
   return __getwd_warn (__buf);
                             ^
/tmp/ccUoq7Wg.o: In function `Zip::RecompressFile(unsigned char*, unsigned int, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, ECTOptions const&)':
zip.cpp:(.text+0xb33): warning: the `getwd' function is dangerous and should not be used.