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 12:07:22
|
On Thu, Jan 17, 2013 at 04:11:42AM -0600, DRC wrote: > On 1/16/13 9:04 AM, Adam Tkac wrote: > > since libjpeg-turbo uses libtool, it should be fairly simple on UN*X systems: > > > > http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html > > > > When you only add new interface, you should perform steps 3., 4. and 5. > > > > So the "-version-info" parameter in Makefile.am will be "-version-info 63:0:1" > > and the output library will be libjpeg.so.62.1.0. However you are right that > > application which uses mem_* functions will fail due to unresolved symbols when you > > run it with old libjpeg.so.62.0.0. > > > > I'm not sure about Windows but I think you don't have to change anything, just > > add new functions. > > OK, that's easy enough. Follow-up Q: > > How best to handle the version script? (libjpeg.map.in) Does it really > matter if these new symbols are also under the version node LIBJPEG_6.2? > Or should they be moved into the LIBJPEGTURBO_6.2 node? 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... Regards, Adam -- Adam Tkac, Red Hat, Inc. |