A few particulars - I am building a 32-bit (i386) version and linking using static libs. Compilation is on a 10.7.5 machine and with both 0.14.8 and 0.15.2, I use:
setenv LDFLAGS "-arch i386 -F/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks -L/Developer/SDKs/MacOSX10.6.sdk/usr/local/lib"
setenv CPPFLAGS "-arch i386 -I/Developer/SDKs/MacOSX10.6.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5"
./configure --disable-demosaic-pack-gpl2 --disable-demosaic-pack-gpl3
make
(and I link to the .libs/libraw.a)
On Windows, all is fine (I'm using your build in a 32-bit app). Using 0.14.8, all is fine on the Mac (as have several prior versions - been with you for years). But, using this build, I have real issues.
- Following the call to RawProcessor.open_file(), my RawProcessor.imagedata.idata.make and .model are garbage (despite open_file() returning no error)
- The sizes.height, .width, etc. are all garbage
- Attempts to call unpack() succeed in that they don't return an error, but I've got no image and memory is not allocated properly.
Now, I will say that raw-identify properly gives the name - either using the dylib or by forcing only the static to be built with:
./configure --disable-demosaic-pack-gpl2 --disable-demosaic-pack-gpl3 --disable-shared --enable-static
Likewise, some simple test code much like that that I compile myself works fine here. I grant that this is odd, but numerous times trying 0.15.2 in my project all end up with the same garbage (static or dynamic link to llcms2) whereas 0.14.8 and all others before that worked just fine. The only thing that's happened in my code is:
LibRaw RawProcessor;
int rval;
if ( (rval = RawProcessor.open_file((const char*) fname.c_str())) != LIBRAW_SUCCESS) {
wxMessageBox(_T("Error opening ") + fname + libraw_strerror(rval));
return true;
}
At that point, I should have the name / model number and I do with 0.14.8 and earlier but not on 0.15.2. I'm game to try any other 0.15.x if I can grab the source.
Craig
Well, after hitting this with
Well, after hitting this with 0.15.3 again, I banged my head against it some more. As far as I can tell, there was something cached in XCode that even a Project, Clean wasn't taking care of. I moved all prior LibRAWs away, did a clean, and rebuilt and voila! No signs things were pointing to these, but I can only assume some structure size difference b/n 0.14 and 0.15 was getting things off.
Yes, major LibRaw versions (0
Yes, major LibRaw versions (0.14 vs 0.15 or 0.13 vs 0.12) are binary incompatible.
-- Alex Tutubalin @LibRaw LLC