Hi Stefan, Le 16/01/2018 à 09:23, Stefan Schmidt a écrit : > 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 > > >> 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.
In Buildroot, the efl package always use the system liblz4. There is no problem reported so far. Also, we dropped the --enable-lua-old option since a while (efl 1.15.x)... https://git.buildroot.net/buildroot/commit/?id=e723eaf564d61064d888b52c4283f6dd456bc765 https://git.buildroot.net/buildroot/commit/?id=92f7591eca0d2b4ff827ed90629be94292c8b102 Best regards, Romain > > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ 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
