Hello.
On 01/16/2018 01:11 PM, Carsten Haitzler wrote: > 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. What you are describing above is just the normal way of handling dependencies on Windows :) They do not believe in a package manager. They believe in shipping all deps in the binary. If you now want to _build_ something as developer with different deps you are on your own. :) > 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/ You are using the win-builds 1.5 release which is almost 3 years old by now? Do they update the packages on their repos? I looked at it for ready build efl packages but never found anything newer than 1.11.2 in it. >From what I can see from the mailing list archives it basically stopped being >active in 2015. Relying on it for easy package installs on windows and making it a requirement for new deps it pretty far fetched in my view. >>> 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. And speed improvement overall, not only ARM. >> 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. None listed or gone the whole way of requesting a CVE and such. Basically the same as we have here in efl. Bugs get fixed and security implications might get noted in a commit message. We do not go the full route of trying to exploit such bugs and request CVE's, issues security patches, mention it in the release or anything. >> 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. If you keep your specific set build flags and hope that we never update some of the versions of our deps. Lets take lua as an example. win-builds does have lua 5.1.5 in its 1.5 release. No luajit, which means you are building with --enable-lua-old. If I follow your logic of not breaking your windows build as you have it right now we could never remove this option or depend on lua versions higher than 5.1.5. > 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). As I mentioned in my proposal the first step would simply be switching the default to system instead of embedded. Which means you would just need to have another build option, like --enable-lua-old, in your windows build script. Removing it would be my plan after a future release. To be brutally honest with you this whole windows build argument is a double edged sword. On linux we sometimes we require new versions just a few days after an upstream release and we let users with older distros sit in the rain. If we set the baseline here to packages from January 2015 we should aim ourselves to support Debian stable and older Ubuntu LTS releases as well. 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
