On Tue, 16 Jan 2018 09:23:54 +0100 Stefan Schmidt <ste...@osg.samsung.com> said:
> Hello. > > > On 01/16/2018 02:40 AM, Carsten Haitzler wrote: > > On Mon, 15 Jan 2018 12:49:14 +0100 Stefan Schmidt <ste...@osg.samsung.com> > > 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 but then i have to scoure the internet for random zip files and hand install those dll's. i've been using the winbuilds pkgs which should get updated like a normal pkg repo. thats what i meant by readily available pkg/dll's/ > > 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> ok - better arm support there. > 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. ok so no real security issues we missed i guess. not listed in release notes above anyway. > 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? those deps have been solved. making lz4 an external only dep would change that and i have a case where if you did this today i would cease being able to build efl for windows (cross-build). > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
