Bug 854695

Just FYI:

https://fedoraproject.org/wiki/Features/libjpeg-turbo-jpeg8-ABI

Thanks!

Fixed in libjpeg-turbo-1.2.1-4.fc19

After discussion with libjpeg and libjpeg-turbo upstreams I consider not to include jpeg8 API/ABI in Fedora and stay with former jpeg6 API/ABI because post-jpeg6 changes are simply useless and wrong and libjpeg upstream didn't present any valid argument for them.

Discussion is on http://sourceforge.net/mailarchive/message.php?msg_id=30352465

I checked libkdcraw and there is really no reason for the jpeg8 requirement. The only interesting piece is the new jpeg_mem_src() function which will be present in next libjpeg-turbo release. Do you know why upstream bumped API/ABI requirement?

I have no idea. It looks like a totally gratuitous bump to me. At least API-wise, last I checked, they didn't really change anything in the code which would require the new API. I'm already looking into patching that out for a future F18 upgrade, I guess we can patch it in Rawhide too, but it may mean having to carry a patch forever. :-(

Looking closer at the history, I think what happened is that some code which silently required libjpeg 8 was introduced, for whatever reason, and then checks were added to fix build issues people encountered. I'm also not sure whether libjpeg-turbo built with the v6 ABI would work with that check removed.

Another complicating factor is that all those things happened in the bundled (and I think partially forked) LibRaw, I wonder whether the same issue happens in the system LibRaw too (and also whether we couldn't just build libkdcraw against the system LibRaw, something I have wanted to investigate for a long time).

> I checked libkdcraw and there is really no reason for the jpeg8 requirement.
> The only interesting piece is the new jpeg_mem_src() function which will be
> present in next libjpeg-turbo release. Do you know why upstream bumped API/ABI
> requirement?

So looking closer, it looks like jpeg_mem_src is really what they want out of jpeg8. So, can we please have the following changeset:
http://sourceforge.net/p/libjpeg-turbo/code/913/
backported to Rawhide and F18 (it's backwards binary-compatible, so it should be doable for F18) ASAP? (Or alternatively, if you're busy, I can do the backport, just tell me if you're OK with that.)

Having that changeset available would greatly help us:
1. providing a fully-featured libkdcraw in Fedora (We also want to push 4.10 to F18 soon, which is why I'm asking for F18 too.) and
2. getting a libkdcraw CMakeLists.txt fix for that (check for jpeg_mem_src specifically rather than the version of the library) submitted for upstream review ASAP (I need an updated libjpeg-turbo build to test the fix with).

(In reply to comment #7)
> > I checked libkdcraw and there is really no reason for the jpeg8 requirement.
> > The only interesting piece is the new jpeg_mem_src() function which will be
> > present in next libjpeg-turbo release. Do you know why upstream bumped API/ABI
> > requirement?
> 
> So looking closer, it looks like jpeg_mem_src is really what they want out
> of jpeg8. So, can we please have the following changeset:
> http://sourceforge.net/p/libjpeg-turbo/code/913/
> backported to Rawhide and F18 (it's backwards binary-compatible, so it
> should be doable for F18) ASAP? (Or alternatively, if you're busy, I can do
> the backport, just tell me if you're OK with that.)
> 
> Having that changeset available would greatly help us:
> 1. providing a fully-featured libkdcraw in Fedora (We also want to push 4.10
> to F18 soon, which is why I'm asking for F18 too.) and

I will backport the patch today.

> 2. getting a libkdcraw CMakeLists.txt fix for that (check for jpeg_mem_src
> specifically rather than the version of the library) submitted for upstream
> review ASAP (I need an updated libjpeg-turbo build to test the fix with).

There are many conflicts between the 913 revision and current libjpeg-turbo-1.2.1 so I built libjpeg-turbo-1.2.90-0.1.20130204svn922.fc19 for rawhide and will include final 1.2.90 into F18, it should be released during this week.

Created attachment 692872 [details]
libkdcraw-4.10.0 build log

I removed libjpeg8 check but libkdcraw build with libjpeg-turbo-1.2.90 failed.

/builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp: In member function 'void RawSpeed::DngDecoderSlices::decodeSlice(RawSpeed::DngDecoderThread*)':
/builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:174:87: error: call of overloaded 'jpeg_mem_src(jpeg_decompress_struct*, unsigned char*, const uint32&)' is ambiguous
         jpeg_mem_src(&dinfo, (unsigned char*)mFile->getData(e.byteOffset), e.byteCount);
                                                                                       ^
/builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:174:87: note: candidates are:
/builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:112:13: note: void RawSpeed::jpeg_mem_src(j_decompress_ptr, unsigned char*, long int)
 static void jpeg_mem_src (j_decompress_ptr cinfo, unsigned char* buffer, long nbytes)
             ^
In file included from /builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/StdAfx.h:68:0,
                 from /builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:1:
/usr/include/jpeglib.h:1008:14: note: void jpeg_mem_src(j_decompress_ptr, unsigned char*, long unsigned int)
 EXTERN(void) jpeg_mem_src JPP((j_decompress_ptr cinfo,
              ^
make[2]: *** [libraw/CMakeFiles/libraw.dir/RawSpeed/DngDecoderSlices.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/builddir/build/BUILD/libkdcraw-4.10.0/x86_64-redhat-linux-gnu'
make[1]: Leaving directory `/builddir/build/BUILD/libkdcraw-4.10.0/x86_64-redhat-linux-gnu'
make[1]: *** [libraw/CMakeFiles/libraw.dir/all] Error 2
make: Leaving directory `/builddir/build/BUILD/libkdcraw-4.10.0/x86_64-redhat-linux-gnu'
make: *** [all] Error 2

(In reply to comment #10)
> Created attachment 692872 [details]
> libkdcraw-4.10.0 build log
> 
> I removed libjpeg8 check but libkdcraw build with libjpeg-turbo-1.2.90
> failed.
> 
> /builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:
> In member function 'void
> RawSpeed::DngDecoderSlices::decodeSlice(RawSpeed::DngDecoderThread*)':
> /builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:
> 174:87: error: call of overloaded 'jpeg_mem_src(jpeg_decompress_struct*,
> unsigned char*, const uint32&)' is ambiguous
>          jpeg_mem_src(&dinfo, (unsigned char*)mFile->getData(e.byteOffset),
> e.byteCount);
>                                                                             
> ^
> /builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:
> 174:87: note: candidates are:
> /builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:
> 112:13: note: void RawSpeed::jpeg_mem_src(j_decompress_ptr, unsigned char*,
> long int)
>  static void jpeg_mem_src (j_decompress_ptr cinfo, unsigned char* buffer,
> long nbytes)
>              ^
> In file included from
> /builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/StdAfx.h:68:0,
>                  from
> /builddir/build/BUILD/libkdcraw-4.10.0/libraw/RawSpeed/DngDecoderSlices.cpp:
> 1:
> /usr/include/jpeglib.h:1008:14: note: void jpeg_mem_src(j_decompress_ptr,
> unsigned char*, long unsigned int)
>  EXTERN(void) jpeg_mem_src JPP((j_decompress_ptr cinfo,
>               ^
> make[2]: *** [libraw/CMakeFiles/libraw.dir/RawSpeed/DngDecoderSlices.o]
> Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: Leaving directory
> `/builddir/build/BUILD/libkdcraw-4.10.0/x86_64-redhat-linux-gnu'
> make[1]: Leaving directory
> `/builddir/build/BUILD/libkdcraw-4.10.0/x86_64-redhat-linux-gnu'
> make[1]: *** [libraw/CMakeFiles/libraw.dir/all] Error 2
> make: Leaving directory
> `/builddir/build/BUILD/libkdcraw-4.10.0/x86_64-redhat-linux-gnu'
> make: *** [all] Error 2

I'm 100% sure that libkdcraw defines it's own jpeg_mem_src which conflicts with libjpeg-turbo jpeg_mem_src definition. libkdcraw should be fixed and shouldn't use it's own jpeg_mem_src when libjpeg.so contains this function.

Yes, this is clearly libkdcraw's fault, I'll fix this.

It's all the more ridiculous that RawSpeed tries to implement its own jpeg_mem_src, considering that:
* CMakeLists.txt only builds RawSpeed if it finds libjpeg 8 (nucleo patched that out when he tried the build.) and
* other LibRaw code assumes the function to be in libjpeg (the custom definition is local to RawSpeed).

So, I fixed the libkdcraw mess in Rawhide, it now detects jpeg_mem_src in libjpeg-turbo and uses it throughout the code. Everything seems fine now.

http://pkgs.fedoraproject.org/cgit/libkdcraw.git/tree/libkdcraw-4.10.0-libjpeg-turbo.patch
https://git.reviewboard.kde.org/r/108821/
http://koji.fedoraproject.org/koji/buildinfo?buildID=382549

Can we please have a libjpeg-turbo-1.2.90 build for F18 too now?

libjpeg-turbo-1.2.90-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libjpeg-turbo-1.2.90-1.fc18

Package libjpeg-turbo-1.2.90-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libjpeg-turbo-1.2.90-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-2174/libjpeg-turbo-1.2.90-1.fc18
then log in and leave karma (feedback).

Now that f18 update has been unpushed, is there any ETA on it being pushed back?

According to,
https://admin.fedoraproject.org/updates/FEDORA-2013-2174

It's because VirtualGL needs rebuilding against this newer libjpeg-turbo, but no details about progress.  libjpeg-turbo-1.2.90-1.fc18 isn't currently an active buildroot override either.

Adam, I can help do override/VirtualGL builds, if that's all that needs doing here.

In particular,

older turbojpeg provides:
libturbojpeg.so()(64bit)
libturbojpeg.so(TURBOJPEG_1.0)(64bit)
libturbojpeg.so(TURBOJPEG_1.1)(64bit)

newer provides:
libturbojpeg.so.0  
libturbojpeg.so.0(TURBOJPEG_1.0)  
libturbojpeg.so.0(TURBOJPEG_1.1)  
libturbojpeg.so.0(TURBOJPEG_1.2)

> older turbojpeg provides:
> libturbojpeg.so()(64bit)
> libturbojpeg.so(TURBOJPEG_1.0)(64bit)
> libturbojpeg.so(TURBOJPEG_1.1)(64bit)

This one is from x86_64, whereas…

> newer provides:
> libturbojpeg.so.0  
> libturbojpeg.so.0(TURBOJPEG_1.0)  
> libturbojpeg.so.0(TURBOJPEG_1.1)  
> libturbojpeg.so.0(TURBOJPEG_1.2)

… I surely hope that this is the i686 version of the package, or we have some serious build issue there!

Of course, the actual change is that the .so changed from unversioned (just .so) to versioned with ".so.0". But a straightforward rebuild of VirtualGL should be all that's needed.

(In reply to comment #18)
> According to,
> https://admin.fedoraproject.org/updates/FEDORA-2013-2174
> 
> It's because VirtualGL needs rebuilding against this newer libjpeg-turbo,
> but no details about progress.  libjpeg-turbo-1.2.90-1.fc18 isn't currently
> an active buildroot override either.
> 
> Adam, I can help do override/VirtualGL builds, if that's all that needs
> doing here.

Done, I've just pushed libjpeg-turbo together with rebuilt VirtualGL into f18-updates-testing.

Package VirtualGL-2.3.2-3.fc18, libjpeg-turbo-1.2.90-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing VirtualGL-2.3.2-3.fc18 libjpeg-turbo-1.2.90-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-2174/VirtualGL-2.3.2-3.fc18,libjpeg-turbo-1.2.90-1.fc18
then log in and leave karma (feedback).

VirtualGL-2.3.2-3.fc18, libjpeg-turbo-1.2.90-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.