Created attachment 285779 [details] build log # source='src/gzip.cc' object='src/gzip.o' libtool=no x86_64-pc-linux-gnu-g++ -I. -I/usr/include/botan-1.10 -march=amdfam10 -O2 -ggdb -pipe -Wall -W -Wno-unused -c -o src/gzip.o src/gzip.cc src/gzip.cc: In member function ‘Botan::u32bit Botan::Gzip_Decompression::eat_footer(const Botan::byte*, Botan::u32bit)’: src/gzip.cc:349:74: error: no matching function for call to ‘min(size_t, Botan::u32bit&)’ src/gzip.cc:350:14: error: ‘class Botan::SecureVector<unsigned char>’ has no member named ‘append’ src/gzip.cc: In member function ‘void Botan::Gzip_Decompression::check_footer()’: src/gzip.cc:380:10: error: ‘class Botan::SecureVector<unsigned char>’ has no member named ‘set’ src/gzip.cc: In member function ‘void Botan::Gzip_Decompression::clear()’: src/gzip.cc:415:11: error: ‘class Botan::SecureVector<unsigned char>’ has no member named ‘destroy’ make[2]: *** [src/gzip.o] Error 1
botan apparently has no interest at all in maintaining backwards API compatibility. They simply renamed or dropped api elements without any support for the older API, even where such support would be easy to maintain, and with C++ inlining at no cost at all. Makes me wonder... The errors reported above are apparently due to the following changesets, which should provide good alternatives as well: 18520c98497d7ce5fab5521b059ba4cdc39a1fdc 2010-09-08 * renamed destroy to clear facca8dd6539ca39201234b6a1178977e7578968 2010-09-15 * replaced append with operator+= using pairs 365203340317c65cb1e8bcd8ee73526908ce26af 2010-10-12 * changed return type of size from u32bit to size_t 1ef53a46779cfd86f4c3c0083264b7453873701c 2010-11-02 * dropped set, must now use resize and copy
*** This bug has been marked as a duplicate of bug 380257 ***
