After more investigations: Something interesting is that in such simple command line example like above the -gdwarf-4 option is somewhat used (but a lot of DWARF5 stuff is brought from libs, something we can't really avoid), but with more complex build where objects are compiled separately, the -gdwarf-4 option should also be set on the linker, while on GCC when building Linux binaries it wasn't needed. That is not a big problem. The big problem I discovered is that MinGW produces garbage DWARF4...
Using the -gdwarf-4 option still produces the DWARF5 format
advzip doesn't offer option to recompress with `store` only when it's smaller without trying another compression
The same happens if the only file in the archive is a directory: advzip fails and the to-be-recompressed zip is deleted: $ mkdir d $ zip d.zip d $ ls -1 d d.zip $ zipinfo -1 d.zip d/ $ advzip -z d.zip Failed stat file d.zip on d.zip [at unsigned int file_size(const string&):file.cc:199] $ ls -1 d
The same happens when re-compressing an archive if the archive only stores one empty file, it even deletes the to-be-compressed archive: $ touch a $ zip z.zip a adding: a (stored 0%) $ ls -1 a z.zip $ advzip -z z.zip Failed stat file z.zip on z.zip [at unsigned int file_size(const string&):file.cc:199] $ ls -1 a $ touch a $ echo b > b $ zip z.zip a b adding: a (stored 0%) adding: b (stored 0%) $ ls -1 a b z.zip $ advzip -z z.zip 284 180 63% z.zip 284 180 63% $ ls -1 a b z.zip $ zipinfo -1 z.zip a...
The bug isn't entirely fixed. Empty file is still not added to the archive if that's the only file to add to the archive: $ touch a $ advzip -a z.zip a a $ ls -1 a $ touch a $ echo b > b $ advzip -a z.zip a b a b $ ls -1 a b z.zip $ zipinfo -1 z.zip a b
The bug isn't entirely fixed. Empty file is still not added to the archive if that's the only file to add to the archive: $ touch a $ advzip -a z.zip a a $ ls -1 a $ touch a $ echo b > b $ advzip -a z.zip a b a b $ ls -1 a b z.zip
This may be related to: https://sourceforge.net/p/advancemame/bugs/258/