When using media-libs/libjpeg-turbo-1.3.0-r2 that supports abi_x86_32 you get custom /usr/include/jconfig.h that includes the corresponding "real" header file depending on the ABI: /usr/include/x86_64-pc-linux-gnu/jconfig.h or /usr/include/i686-pc-linux-gnu/jconfig.h. On the other hand kde-base/gwenview-4.10.5 checks /usr/include/jconfig.h and expects to find JPEG_LIB_VERSION define inside (using regexp). It's done in the gwenview-4.10.5/lib/CMakeLists.txt. But as file was replaced by multilib custom file the define is not there and it breaks during configure phase: -- Looking for libjpeg version in /usr/include/jpeglib.h -- No version defined in /usr/include/jpeglib.h, looking for jconfig.h -- Found jconfig.h: /usr/include/jconfig.h -- Looking for libjpeg version in /usr/include/jconfig.h CMake Error at lib/CMakeLists.txt:36 (message): Unknown libjpeg version: Reproducible: Always
*** Bug 479512 has been marked as a duplicate of this bug. ***
It is most certainly related to this bug: 479502
I can confirm this build failure on my ~amd64 laptop. With the new jpeg-turbo introduced I had more than 50 packages requiring rebuilding. This was the only one to fail and it did so in the setup phase as explained previously.
I'm on KDE 4.10.97 from the kde overlay and the problem is also there with kde-base/gwenview-4.10.97.
The problem is that lib/CMakeLists.txt tries to parse /usr/include/jconfig.h directly, instead of running it through the pre-processor. With the new multilib wrapper stuff, JPEG_LIB_VERSION is defined in /usr/include/${CHOST}/jconfig.h, which gets #include-d into /usr/include/jconfig.h.
Copying libjpeg-turbo maintainers.
The issue appears to be fixed with kde-base/gwenview-4.10.5-r1 which was released earlier today. To those (like myself) who were experiencing this problem, resync portage and the new version should be drawn into the queue. I hope this helps.
This has been fixed in both gx86 and the kde overlay
