On 13/02/2014 10:18, Richard Hughes wrote: > On 13 February 2014 00:01, <marti.ma...@littlecms.com> wrote: > I've run the colord test suite against the new lcms2. There are a lot > of compiler warnings now like this: > > In file included from cd-create-profile.c:27:0: > /usr/include/lcms2.h:1568:14: note: expected ‘cmsContext’ but argument > is of type ‘struct CdIcc *’ > CMSAPI cmsHPROFILE CMSEXPORT cmsCreate_sRGBProfileTHR(cmsContext > ContextID);
That's because the meaning of the 'cmsContext' has now changed in this new version. Previously cmsContext was 'any opaque void * value that the caller wanted to provide'. Now the cmsContext is a pointer to a (private) library defined structure that holds the library state. One element of this structure is a userdata pointer that is 'any opaque void * value that the caller wanted to provide'. This change in behaviour is unfortunate but is necessary to solve some nasty issues with threading and/or with multiple callers to the same shared library. This means that any code that uses the old THR functions will need to be updated. The update is not hard, but I appreciate this isn't much solace to people whose code now fails. The only thing I can say is that if you were using the old THR functions in a shared library build, then there was every possibility that it'd end up crashing anyway due to interference between callers. To mitigate against this, 2 things have been done. Firstly, people can build the library with CMS_CONTEXT_IN_LEGACY_MODE and they will get the old behaviour. Hopefully people should only do this for static library builds. Secondly, for people who happen to be using small positive integers for the cmsContext value, Marti has a horrible hack/"clever piece of engineering" in there that recognises this case and works around it. > What might be a better thing to do is have a global function > cmsSetContextMode() which enables the new functionality at runtime > *if* the project has ported to the new cmsCreateContext() code. The > alternative is you have to bump the soname. Sorry to be grumpy. A global function to set a global state would require a global variable. This would entirely break the whole intention of this work which is enable multiple callers to be able to use the same library independently. If you're resigning yourself to adding a new call to the code, you might as well just change to the newer context handling. A .soname bump might be nice though, yes. That's Martis call. 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
