Bug 479476 – media-libs/freeimage-3.15.4 with media-libs/libjpeg-turbo-1.3.0-r2 - Source/transupp.c:136:42: error: ‘struct jpeg_compress_struct’ has no member named ‘min_DCT_h_scaled_size’

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Aleksander 2013-08-02 08:41:03 UTC]

Created attachment 354878 [details]
build.log

Cannot rebuild media-libs/freeimage after upgrading media-libs/libjpeg-turbo. If downgrade media-libs/libjpeg-turbo to 1.3.0 then media-libs/freeimage builds fine.

[Comment 1 Aleksander 2013-08-02 08:41:59 UTC]

Created attachment 354880 [details]
emerge --info

[Comment 2 Samuli Suominen (RETIRED) 2013-08-02 08:48:40 UTC]

This type of patch will be required,

#if JPEG_LIB_VERSION >= 80
blahblah, here is cinfo.min_DCT_v_scaled_size
#else
blahblah, here is cinfo.min_DCT_scaled_size
#endif

[Comment 3 Samuli Suominen (RETIRED) 2013-08-02 15:13:59 UTC]

Created attachment 354932 [details, diff]
Make the package build against >= libjpeg-turbo-1.3.0-r2

The real problem here is that transupp.{c,h} files changed API after released of IJG JPEG 7 and newer

This patch copies the compatible headers from the libjpeg-turbo tarball. It's propably best you can do with this, jpeg really has transupp* which is not part of libjpeg itself and often when libjpeg is bundled, someone makes use of the transupp as well, which is what happened here it seems

Anyway, should be good to go in portage with ~arch revision bump

[Comment 4 Samuli Suominen (RETIRED) 2013-08-02 15:45:40 UTC]

Or use the internal copy of libjpeg if they insist in being stuck with jpeg-8d and use mostly example transupp.c and transupp.h files

So even if you remove most of the jpeg directory in src_prepare() you still have to copy version specific internal files from there ^^

^^ That mess could warrant using internal jpeg

Unless someone can manage similar patch for jpeg-9 as attached here

meh. whatever.

[Comment 5 Jouni Kosonen 2013-08-02 22:33:27 UTC]

What actually happened to the JPEG_LIB_VERSION here?
From looking at the generated binpackages,

media-libs/libjpeg-turbo-1.3.0-r1 had
#define JPEG_LIB_VERSION 80

media-libs/libjpeg-turbo-1.3.0-r2 has
#define JPEG_LIB_VERSION 62

[Comment 6 Jouni Kosonen 2013-08-03 00:55:10 UTC]

(In reply to Jouni Kosonen from comment #5)
> What actually happened to the JPEG_LIB_VERSION here?
> From looking at the generated binpackages,
> 
> media-libs/libjpeg-turbo-1.3.0-r1 had
> #define JPEG_LIB_VERSION 80
> 
> media-libs/libjpeg-turbo-1.3.0-r2 has
> #define JPEG_LIB_VERSION 62

Nevermind, found the explanation in bug #479502

[Comment 7 SpanKY 2013-08-14 17:56:25 UTC]

Comment on attachment 354932 [details, diff]
Make the package build against >= libjpeg-turbo-1.3.0-r2

i'm not keen on moving away from the virtual

[Comment 8 SpanKY 2013-08-14 17:56:30 UTC]

(In reply to Samuli Suominen from comment #4)

we've done a lot of work to unbundle the libs.  we don't want to go back to using the internal jpeg.  we keep the trans files since, as you pointed out, libjpeg itself does not include those functions yet freeimage itself uses them.

[Comment 9 SpanKY 2013-08-14 18:35:25 UTC]

(In reply to Samuli Suominen from comment #2)

this ifdef approach "works" for most things.  the jpeg_compress_struct does not have that member in the 62 API.  so even though we can make it build for most members, it's not going to for that one.

seems like freeimage is expecting the API that jpeg-7 has provided since Jun 2009 and libjpeg-turbo in our tree used to provide.  but now the latest libjpeg-turbo has restricted its API back to the jpeg-6 days.  so because of libjpeg-turbo, no package in the tree may use any of the newer APIs that jpeg has introduced ?  that doesn't seem right.

[Comment 10 Samuli Suominen (RETIRED) 2013-08-15 08:54:26 UTC]

libjpeg-turbo-1.3.0-r2 = libjpeg.so.62 plus jpeg_mem_{dest,src} backported from so.8 plus libjpeg-turbo's own API that is mandatory for Mozilla products and Chromium as well, plus some others as this is the widely adapted version in open source now, this is the ABI both Fedora and Debian are going as well. it's what the original jpeg-6b author endorses as well.

libjpeg-9-r1 = libjpeg.so.9 containing the two functions i've mentioned before

libjpeg-7 = libjpeg.so.7, dead
libjpeg-8* = libjpeg.so.8, dead, and was only pretended to be supported in libjpeg-turbo, as it was never complete and without the SmartScale the IJG has in their .so.8

therefore the virtual is pulling in, to ensure the jpeg_mem_{dest,src} are available which are required for anything using the Quake engine, for example
either >=libjpeg-turbo-1.3.0-r2 or >=jpeg-9 in ~arch now

so this is a case of freeimage upstream going for poor decision as to what their jpeg implementation should be, and they propably thinking it's safe to use the new API since they bundle it

yes i realize it's far from ideal. IJG really dropped the ball here.

[Comment 11 Samuli Suominen (RETIRED) 2013-08-15 08:56:01 UTC]

either force libjpeg-turbo like other ebuilds in-tree already do, like firefox and chromium, or patch it to support both libjpeg.so.62 and libjpeg.so.9

[Comment 12 SpanKY 2013-08-15 16:51:36 UTC]

(In reply to Samuli Suominen from comment #10)

the issue isn't with additional functions.  between jpeg-6 and jpeg-7, they changed the layout of some structures.  specifically, expanding the scaled fields to include proper height/width splitting rather than "size".  by forcing the API of libjpeg-turbo to be 62, you've banned these extended fields.

i don't really see how blaming the jpeg group for libjpeg-turbo refusing to support newer APIs that they've added works.  all i see here is libjpeg-turbo restricting itself to the ancient API and refusing to support anything newer.

i also don't really see how other distros matter here.  if people want to take binaries from other places and run them on Gentoo, they can do so now and install the SLOT=62 package.

if anything, i'm inclined to have freeimage force media-libs/jpeg seeing as how it provides a more feature complete API.

[Comment 13 Samuli Suominen (RETIRED) 2013-08-16 11:58:05 UTC]

libjpeg-turbo has it's own more enhanced API which is being used by firefox, chromium, virtualgl, bumblebee, about any VNC software, ...
and libjpeg-turbo has refused to support other than the two functions in the longterm API, and have stated they have no intentions of finalizing the .so.8 or to start with .so.9.  this changes the nature of the virtual from switching between compatible ABIs to incompatible one that is catched by preserved-libs and rebuilt for.
and enabling the .so.7 or the incomplete .so.8 doesn't make sense just for freeimage, when staying with .so.62 has clear benefits (of not needing additional media-libs/jpeg:62 SLOT installed for compability with binaries produced outside of Gentoo) and having the binaries using .so.62 under also use libjpeg-turbo and it's benefits

[Comment 14 Samuli Suominen (RETIRED) 2013-08-16 13:32:02 UTC]

we could reevaluate what libjpeg is for us if that is required, in which case i'd rename jpeg-9's libjpeg.so to libjpeg-smartscale.so
which means media-libs/jpeg is removed from the virtuals and becomes parallel installable with media-libs/libjpeg-turbo
media-libs/jpeg-9-r2 would be libjpeg-smartscale.so{,.9} for anything using the new IJG features, like freeimage and libjpeg-turbo stay as libjpeg.so.62 w/ jpeg_mem_{dest,src} for the rest

[Comment 15 Cengiz Gunay 2013-08-19 21:03:40 UTC]

Is there a solution to this yet? I am unable to downgrade media-libs/libjpeg-turbo to 1.3.0. Also, I still don't see the requirement for media-libs/jpeg in media-libs/freeimage-3.15.4's dependencies. I gave more information about my situation in the forum: http://forums.gentoo.org/viewtopic-p-7377080.html#7377080

[Comment 16 Cengiz Gunay 2013-08-26 15:47:41 UTC]

There was a solution to this problem in the forum: libjpeg-turbo-1.3.0-r2 accepts a configure option to enable jpeg7.

So if we modify media-libs/libjpeg-turbo/libjpeg-turbo-1.3.0-r2.ebuild (configure with jpeg7 support):

Code:	
   ECONF_SOURCE=${S} \
   econf \
      $(use_enable static-libs static) \
      --with-mem-srcdst \
      --with-jpeg7 \
      "${myconf[@]}"
}

ebuild /usr/portage/media-libs/libjpeg-turbo/libjpeg-turbo-1.3.0-r2.ebuild manifest
emerge -1 libjpeg-turbo
emerge @preserved-rebuild 
emerge -1 freeimage

Worked for two people so far to have a coherent emerge. I'm not sure if this helps with the other problems.

[Comment 17 Small_Penguin 2013-08-28 16:14:31 UTC]

Solution from comment #16 seems to work, except (again) for the rebuild madness. From that point of view, solutions from comment #3 or comment #7 seem to be a better approach, since freeimage is the only package on my system that breaks. Anyway, thanks to all for your patches, hopefully some will fix this in tree ;-)

[Comment 18 Ron 2013-09-07 07:06:33 UTC]

(In reply to Cengiz Gunay from comment #16)
> There was a solution to this problem in the forum: libjpeg-turbo-1.3.0-r2
> accepts a configure option to enable jpeg7.
> 
> So if we modify media-libs/libjpeg-turbo/libjpeg-turbo-1.3.0-r2.ebuild
> (configure with jpeg7 support):
> 
> Code:	
>    ECONF_SOURCE=${S} \
>    econf \
>       $(use_enable static-libs static) \
>       --with-mem-srcdst \
>       --with-jpeg7 \
>       "${myconf[@]}"
> }
> 
> ebuild /usr/portage/media-libs/libjpeg-turbo/libjpeg-turbo-1.3.0-r2.ebuild
> manifest
> emerge -1 libjpeg-turbo
> emerge @preserved-rebuild 
> emerge -1 freeimage
> 
> Worked for two people so far to have a coherent emerge. I'm not sure if this
> helps with the other problems.

Thanks for the fix this has been driving me nuts, in general the jpeg libraries have been insane lately depending on the application I've seen 62 and 80 needed I have yet seen a call for 90.

[Comment 19 Julian Ospald 2013-09-07 19:04:53 UTC]

Mike, what do you think about adding a "vanilla" useflag, so that it's not left entirely broken in such cases. Since the bundled libs are quite a mess, some sort of breakage always occurs after version bump of freeimage or one of it's deps. (like "raw" useflag was recently broken)

[Comment 20 Mark Wright 2013-09-08 03:13:11 UTC]

Created attachment 358230 [details, diff]
libjpeg-turbo patch

Christian Heimes fixed for us a while ago:
http://sourceforge.net/p/freeimage/discussion/36111/thread/f9e15873/
copying the relevant files from his fork:
https://bitbucket.org/tiran/freeimageturbo
into the attached patch, and then this change to the ebuild:

# diff -ur /usr/portage/media-libs/freeimage/freeimage-3.15.4.ebuild /usr/local/portage/media-libs/freeimage/freeimage-3.15.4.ebuild 
--- /usr/portage/media-libs/freeimage/freeimage-3.15.4.ebuild	2013-06-13 22:31:20.000000000 +1000
+++ /usr/local/portage/media-libs/freeimage/freeimage-3.15.4.ebuild	2013-09-08 13:02:54.018920603 +1000
@@ -40,8 +40,9 @@
 S=${WORKDIR}/${MY_PN}
 
 src_prepare() {
+	epatch "${FILESDIR}"/${PN}-3.15.4-libjpeg-turbo.patch
 	cd Source
-	cp LibJPEG/{transupp.c,transupp.h,jinclude.h} . || die
+	cp LibJPEG/{transupp.c,transupp.h,jpegcomp.h,jpegint.h,jinclude.h} . || die
 	cp LibTIFF4/{tiffiop,tif_dir}.h . || die
 	rm -rf LibPNG LibMNG LibOpenJPEG ZLib OpenEXR LibRawLite LibTIFF4 LibJPEG || die
 	cd ..
# 

then it builds.

[Comment 21 Mark Wright 2013-09-08 04:20:14 UTC]

Thanks to Christian Heimes for porting freeimage to use libjpeg-turbo, freeimage-3.15.4-libjpeg-turbo.patch.gz is from Christian's fork at https://bitbucket.org/tiran/freeimageturbo. Fixes bug 479476. Thanks to Aleksander for reporting, Samuli Suominen, SpanKY for comments on how it should be fixed.

[Comment 22 Mark Wright 2013-09-08 05:19:49 UTC]

Created attachment 358238 [details, diff]
same patch just at a higher directory so it applies easy after the cd Source

I applied another commit to only apply the libjpeg-turbo patch if libjpeg-turbo is installed, so the combination of those 2 commits is this change:

argus / # diff -ur /usr/portage/media-libs/freeimage/freeimage-3.15.4.ebuild /usr/local/portage/media-libs/freeimage/freeimage-3.15.4.ebuild 
--- /usr/portage/media-libs/freeimage/freeimage-3.15.4.ebuild	2013-06-13 22:31:20.000000000 +1000
+++ /usr/local/portage/media-libs/freeimage/freeimage-3.15.4.ebuild	2013-09-08 14:57:14.916254230 +1000
@@ -1,6 +1,6 @@
 # Copyright 1999-2013 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/media-libs/freeimage/freeimage-3.15.4.ebuild,v 1.4 2013/06/13 12:29:48 xmw Exp $
+# $Header: /var/cvsroot/gentoo-x86/media-libs/freeimage/freeimage-3.15.4.ebuild,v 1.5 2013/09/08 04:19:39 gienah Exp $
 
 EAPI="4"
 
@@ -41,6 +41,11 @@
 
 src_prepare() {
 	cd Source
+	if has_version ">=media-libs/libjpeg-turbo-1.2.1"; then
+		# Patch from Christian Heimes's fork (thanks) https://bitbucket.org/tiran/freeimageturbo
+		epatch "${FILESDIR}"/${PN}-3.15.4-libjpeg-turbo.patch.gz
+		cp LibJPEG/{jpegcomp.h,jpegint.h} . || die
+	fi
 	cp LibJPEG/{transupp.c,transupp.h,jinclude.h} . || die
 	cp LibTIFF4/{tiffiop,tif_dir}.h . || die
 	rm -rf LibPNG LibMNG LibOpenJPEG ZLib OpenEXR LibRawLite LibTIFF4 LibJPEG || die
argus / #

[Comment 23 Bernd Buschinski 2013-09-08 14:18:51 UTC]

Thanks for fixing this bug,
but I would greatly appreciate a revbump after all those changes.

[Comment 24 Peter Asplund 2013-10-05 17:26:15 UTC]

Is this in the tree yet?

[Comment 25 Steffen Schaumburg 2013-10-06 15:36:02 UTC]

It's in 3.15.4, no revbump. Note that this also affected media-libs/freeimage-3.15.3-r2. Patch works for me, tyvm :)

[Comment 26 Dominique Michel 2013-12-15 15:29:36 UTC]

work fine here too