Re: [Libjpeg-turbo-devel] Enabling the in-memory source/destination managers in libjpeg-turbo's def
SIMD-accelerated libjpeg-compatible JPEG codec library
Brought to you by:
dcommander
From: Adam T. <at...@re...> - 2013-01-17 14:43:18
|
On Thu, Jan 17, 2013 at 07:56:12AM -0600, DRC wrote: > On 1/17/13 6:05 AM, Adam Tkac wrote: > > In short, all current symbols must be in "version node" LIBJPEG_6.2 and new > > symbols can be put into the same node as well (but you can put them into any > > version node because they are new). > > > > Long answer is this article: > > http://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html > > > > especially section 3.5 of http://people.redhat.com/drepper/dsohowto.pdf tells > > about symbol versioning, shipping multiple versions of one symbol etc... > > OK, I just remember someone complaining at one time because > libjpeg-turbo was exposing some of its internal symbols (jsimd_*, etc.) > in the LIBJPEG_6.2 node, thus making it produce different results with > readelf than jpeg-6b. So unless there are any objections, I'd feel a > little better putting these symbols under the LIBJPEGTURBO_6.2 node to > make it clear that they aren't part of jpeg-6b. Either way, an > application would fail as soon as it tried to invoke the jpeg_mem_* > function with an implementation that didn't support it, so maybe I'm > just being overly anal here. I checked that IJG's libjpeg has all functions in LIBJPEG_9.0 namespace so from my point of view you can put mem_* functions into either LIBJPEGTURBO_6.2 or LIBJPEG_6.2. None of them will be binary compatible with IJG's libjpeg. Note that IJG ships all symbols in LIBJPEG_9.0 namespace so even "standard", i.e. jpeg6, symbols from IJG's libjpeg aren't compatible with our jpeg6 symbols. So in my opinion we just need to keep API compatibility with IJG, not ABI compatibility... Regards, Adam -- Adam Tkac, Red Hat, Inc. |