Hello.
On 01/16/2018 02:40 AM, Carsten Haitzler wrote: > On Mon, 15 Jan 2018 12:49:14 +0100 Stefan Schmidt <[email protected]> > said: > >> Hello. >> >> >> When looking through our builds (in particularly the one which uses the >> liblz4 from system build option) I stumbled over now deprecated functions. >> >> modules/evas/image_savers/tgv/evas_image_save_tgv.c:128:9: warning: >> 'LZ4_compressHC' is deprecated: use LZ4_compress_HC() instead >> [-Wdeprecated-declarations] Giving it a further look revealed that we, once >> again, missed quite a few liblz4 releases and did not update our copy. They >> are at version 1.8 now (switched version schemes after r131 which is the last >> we have in tree). https://github.com/lz4/lz4/releases I think its time we >> finally switch to having liblz4 as a normal system dependency by default (I >> am willing to have the in-tree version for another release as fallback). >> Anyone wanting to point out now how complicated that will be for our multi >> platforms strategy. Homebrew has a recent version and the liblz4 project does >> actually offer 32 and 64 bit binaries as well. That is way better than other >> dependencies we have. I am willing to switch the default dependency to system >> and also update the in-tree copy one last time. Are there some real problems >> I overlooked? regards Stefan Schmidt > windows. external liblz4... at least i don't have a ready available pkg/dll i > can install with it in. The project offer builds for Windows directly. From the link I posted above you can see them easily: https://github.com/lz4/lz4/releases/download/v1.8.1.2/lz4_v1_8_1_win32.zip https://github.com/lz4/lz4/releases/download/v1.8.1.2/lz4_v1_8_1_win64.zip > also... even if we have missed updates... have we missed anything we NEED? > like > a security fix? have we missed major performance improvements? > We have often missed security updates with lz4 in the past. 2014 was bad in that regard. Cedric updated at that point. But since then we only did two updates on it (both done by me). Right now there are 7 new version we have not updated against because nobody follows the liblz4 development or cares enough to update. The last time I updated it was in 2016. Regarding changes we are missing out. Here are some small extracts from the changelogs we should be interested in: v1.7.3: Improved: Small decompression speed boost Improved: Small compression speed improvement on 64-bits systems Improved: Small compression ratio and speed improvement on small files Improved: Significant speed boost on ARMv6 and ARMv7 New liblz4-dll project, by @inikep <https://github.com/inikep> v1.7.4 compiler : fix : compilation on gcc 4.4 ( #272 <https://github.com/lz4/lz4/issues/272> ), reported by @totaam <https://github.com/totaam> Improved : much better speed in |-mx32| mode v1.7.5 lz4hc : new high compression mode, by @inikep <https://github.com/inikep> : levels 10-12 compress more (and slower), 12 is highest level v1.8.1.2 LZ4 v1.8.1 most visible new feature is its support for *Dictionary compression* . LZ4 v1.8.1 also offers improved performance at ultra settings (levels 10+). "Compared with previous version, the new parser uses less memory (from 384KB to 256KB), performs faster, compresses a little bit better (not much, as it was already close to theoretical limit), and resists pathological patterns which could destroy performance (see #339 <https://github.com/lz4/lz4/issues/339>)," perf : faster and stronger ultra modes (levels 10+) perf : slightly faster compression and decompression speed perf : fix bad degenerative case, reported by @c-morgenstern <https://github.com/c-morgenstern> Security wise I can only see one entry in CVE for lz4. Which is the one from 2014. No proofs that there have been new ones fixed. But it is not like all projects really track security issues they fix. (we do not) Often enough thinks like buffer overflows or memory corruptions just gets fixed during development without making a big security theater with websites and logos out of it. And I honestly have a hard time to understand this resistance to use liblz4 as a system dependency. We have _tons_ of dependencies that folks using efl must handle on any platform. Given that liblz4 is available on Linux distros, osx homebrew and as Windows binaries it actually might be an easier dep compared to others. (Do people ony windows use luajit or are they still use --enable-lua-old?) What is so special about the lz4 code that we should have it embedded into our tree? I understand why we did it initially (the project has simply been some c and h files), but since has changed a lot since 2014. regards Stefan Schmidt ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
