Cristian Rodríguez <[email protected]> wrote: > El 07/05/12 06:23, Miroslav Lichvar escribió: > > On Sat, May 05, 2012 at 05:34:31PM -0400, Cristian Rodríguez wrote: > >> This has the advantage of being more efficient than the included
Btw, how much more efficient and on what hardware? Based on previous experience (in a project not related to FLAC) on x86_64 (Core2 Duo), I don't recall the MD5 performance of OpenSSL ASM being significantly faster than the equivalent C code (from gnulib). SHA1 was a different story, but I still decided it wasn't worth my time/effort to maintain (especially extra testing time to ensure code works with and without OpenSSL). > > Isn't the OpenSSL license incompatible with GPL? IANAL, but I think > > the flac and metaflac utilities can't be linked with OpenSSL unless > > there is an exception in the flac license which would require getting > > the permission from all contributors. > > flac and metaflac do not use openSSL, only libFLAC does. But since flac/metaflac use libFLAC, I suspect (IANAL) the relationship can be transitive. (But being an optional dependency helps as distros can avoid potential issues). > Personally I don't see any technical reason to use a different library > other than politics and obscure potential license incompatibilities. OpenSSL doesn't have a good track record as far as ABI/API stability is concerned (though I think the hash APIs are more stable). Perhaps disabling OpenSSL auto-detection (and only enabling it when explicitly configured) is better? One issue I've noticed in the (fast-moving) Ruby world: The ruby-core mailing list frequently sees segfault reports due to the "openssl" Ruby extension using one version/installation of OpenSSL and another Ruby extension (e.g. EventMachine, curl) using a different OpenSSL version. This is common occurrence, as distros will often ship with multiple OpenSSL versions to accomodate different apps and often Ruby installations/extensions are installed in home directories that aren't upgraded as the same time as the distro itself. I think these issue is a product of both the Ruby world moving too fast and OS distros moving too slowly, but it's the unfortunate reality Rubyists have to deal with :/ I'd rather libFLAC sidestep these potential issues entirely. _______________________________________________ flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
