On 13/02/2014 11:48, Richard Hughes wrote: > On 13 February 2014 12:35, <marti.ma...@littlecms.com> wrote: >> 1) Any client using THR functions and the lib as shared object >> is basically broken. if a client sets a listener or plug-in, >> it got events from any other clients of the .so, with >> obviously unexpected user data format. This causes segfaults. > > Right, and in the case of the ghostscript guys that makes complete > sense. If you're a single threaded application or command line program > using lcms that argument breaks down somewhat.
No. Ghostscript as supplied by us is statically linked with a private copy of lcms2. We don't suffer from the problem (unless people use us as a lib and also call lcms2). However distros insist on going against our advice and changing our code to work with shared libs. (There is a flame war to be had here, so let's not go down that route now). If you're a single threaded application or command line program using lcms *as a shared library* you are absolutely in the firing line for the bug described above. > Okay, I agree. But you can't pretend you're not breaking ABI by fixing > bugs in the API. The argument "this was broken for some users" doesn't > mean you can break it for most users. I disagree with your characterisation of the change. A truer one would be "the existing code was broken for all users of the shared library in a way that will cause (possibly) infrequent but catastrophic failures in way that will be exceptionally hard to detect and debug" whereas "the new code gives obvious repeatable crashes indicating that you should fix the problem". Personally, I have to say that I dislike the 'magically detect small integer values' hack. I'd vote for ditching it if that's the thing that's causing problems. >> I agree a .soname bump should be required here. I can even >> do a major version bump to lcms2-3.0, your feedback would >> be appreciated. > > Well, you *have* to bump LT_REVISION and I would argue that LT_CURRENT > is required as well. Of course, if you bump LT_CURRENT then world and > dog will want liblcms2.so.3 parallel installable with liblcms2.so.2. > It's not that hard to package the two versions in parallel. Whether it > should be called lcms3 is another issue altogether. Possibly a stupid question, but could we build the current library twice? Once with the CMS_CONTEXT_IN_LEGACY_MODE to give liblcms2.so.2 and once without to give liblcms2.so.3 ? Robin ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
