Created attachment 355182 [details] build log media-tv/xawtv-3.95-r2 fails to compile against media-libs/libjpeg-turbo-1.3.0-r2: libng/plugins/conv-mjpeg.c: In function ‘mjpg_yuv_init’: libng/plugins/conv-mjpeg.c:232:18: error: ‘struct jpeg_compress_struct’ has no member named ‘do_fancy_downsampling’ The corresponding part of the header is enclosed with a preprocessor guard: #if JPEG_LIB_VERSION >= 70 boolean do_fancy_downsampling; /* TRUE=apply fancy downsampling */ #endif I must confess that I'm somewhat worried that this conditional inclusion of the field might cause layouts of this structure to be incompatible between client application and library. I don't remember where, but some application I worked with recently made sure not to use conditionals for structure members. In any case, the 1.3.0 install had the following line: /usr/include/jconfig.h:#define JPEG_LIB_VERSION 80 In the 1.3.0-r2 ebuild the corresponding line reads /usr/include/jconfig.h:#define JPEG_LIB_VERSION 62 Looking at a diff of the ebuild, I see quite a lot of changes, but the most likely one seems to be the removal of --with-jpeg${JPEG_ABI} as a configure switch. bug #479502 comment #3 indicates that the decreased version number might be intentional. In that case, perhaps xawtv should depend on media-libs/jpeg instead of virtual/jpeg?
I had a look at this whole jpeg vs. libjpeg-turbo issue and it seems to me that the proper solution is making sure that xawtv doesn't unneccessarily depend on newer libjpeg API and ABI. So I enclosed the relevant line in conv-mjpeg.c in the same kind of preprocessor guard used in the jpeglib.h header. The result compiled just fine, everything looks good. Upstream apparently did the same: http://git.linuxtv.org/xawtv3.git/commitdiff/20d4a7272c16a27e4e43dc94659f825367839bfa So bumping xawtv to 3.103 might be an alternative. Although I suggest you do the patch for the currently stable 3.95-r2 and offer 3.103 for testing first. Do you want a separate bug report to take care of this version bump?
xawtv worked fine for libjpeg.so.62 in the past, and support for later jpeg's have been patched in, so surely we can manage reverting the patch / conditionalizing it / ...
(In reply to Martin von Gagern from comment #1) > So bumping xawtv to 3.103 might be an alternative. Although I suggest you do > the patch for the currently stable 3.95-r2 and offer 3.103 for testing > first. Thanks for the research! + 06 Aug 2013; Samuli Suominen <ssuominen@gentoo.org> xawtv-3.95-r2.ebuild, + files/xawtv-3.95-jpeg-7.patch: + Install Xawtv app-defaults to correct directory at /usr/share/X11. Fix + building with libjpeg.so.62 API wrt #479848 by Martin von Gagern > Do you want a separate bug report to take care of this version bump? Yes, please. Version bump will need more time I don't have right now, so bug report should be filed.
(In reply to Samuli Suominen from comment #3) Thanks for fixing this! > Version bump will need more time I don't have right now, so > bug report should be filed. I see bug #358013 already has a matching bump request.
