Bug 854695 - Backport jpeg_mem_{src,dest} functions
Backport jpeg_mem_{src,dest} functions
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libjpeg-turbo (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-05 11:07 EDT by Rex Dieter
Modified: 2017-01-20 11:16 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-02 14:51:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
libkdcraw-4.10.0 build log (66.25 KB, text/plain)
2013-02-04 11:39 EST, nucleo
no flags Details

  None (edit)
Description Rex Dieter 2012-09-05 11:07:00 EDT
there's at least one upstream kde library author (libkdcraw) who apparently has removed compatibility for < libjpeg8 , so I suppose it's time to consider building fedora's own libjpeg-turbo using the --with-jpeg8 switch.

Knowing this changes api/abi, I understand that f19 is the earliest this can be considered.
Comment 2 Rex Dieter 2012-10-18 09:35:48 EDT
Thanks!
Comment 3 Adam Tkac 2012-10-24 10:10:00 EDT
Fixed in libjpeg-turbo-1.2.1-4.fc19
Comment 4 Adam Tkac 2013-01-16 11:04:49 EST
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?
Comment 5 Kevin Kofler 2013-01-16 12:28:32 EST
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. :-(
Comment 6 Kevin Kofler 2013-01-16 12:42:02 EST
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).
Comment 7 Kevin Kofler 2013-01-31 22:53:45 EST
> 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).
Comment 8 Adam Tkac 2013-02-04 06:06:16 EST
(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).
Comment 9 Adam Tkac 2013-02-04 10:37:06 EST
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.
Comment 10 nucleo 2013-02-04 11:39:23 EST
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
Comment 11 Adam Tkac 2013-02-04 12:09:32 EST
(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.
Comment 12 Kevin Kofler 2013-02-04 14:25:52 EST
Yes, this is clearly libkdcraw's fault, I'll fix this.
Comment 13 Kevin Kofler 2013-02-04 14:28:07 EST
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).
Comment 14 Kevin Kofler 2013-02-06 17:08:19 EST
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?
Comment 15 Fedora Update System 2013-02-08 09:49:35 EST
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
Comment 16 Fedora Update System 2013-02-09 06:23:14 EST
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).
Comment 17 Julian Sikorski 2013-02-12 15:10:00 EST
Now that f18 update has been unpushed, is there any ETA on it being pushed back?
Comment 18 Rex Dieter 2013-02-13 08:56:03 EST
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.
Comment 19 Rex Dieter 2013-02-13 08:59:11 EST
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)
Comment 20 Kevin Kofler 2013-02-13 22:31:54 EST
> 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.
Comment 21 Adam Tkac 2013-02-20 06:36:42 EST
(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.
Comment 22 Fedora Update System 2013-02-21 00:45:10 EST
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).
Comment 23 Fedora Update System 2013-03-02 14:51:40 EST
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.

Note You need to log in before you can comment on or make changes to this bug.