Summary: | New version of media-libs/libjpeg-turbo-1.3.0-r2 installs libjpeg.so/62 as default implementation | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mathieu Segaud <mathieu.segaud> |
Component: | [OLD] Library | Assignee: | Samuli Suominen (RETIRED) <ssuominen> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | anarchy, derk.tebokkel, hasufell, polynomial-c |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=479818 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Mathieu Segaud
2013-08-02 12:33:37 UTC
(In reply to Mathieu Segaud from comment #0) > When emerging new version 1.3.0-r2 of libjpeg-turbo, the libjpeg.so symlink > points to libjpeg.so.62 and not libjpeg.so.8, which is required by some > packages to build. > > and causing a massive rebuild of all bins linked against libjpeg.so > > barad-dur lib # ls -l libjpeg.so* > lrwxrwxrwx 1 root root 17 2 août 13:28 libjpeg.so -> libjpeg.so.62.1.0 > lrwxrwxrwx 1 root root 17 2 août 13:28 libjpeg.so.62 -> > libjpeg.so.62.1.0 > -rwxr-xr-x 1 root root 276960 2 août 13:27 libjpeg.so.62.1.0 > lrwxrwxrwx 1 root root 16 1 août 15:18 libjpeg.so.8 -> libjpeg.so.8.0.2 > -rwxr-xr-x 1 root root 276976 1 août 15:18 libjpeg.so.8.0.2 > > I thought that it was preserved but I know both versions were present in the > previous versions of libjpeg-turbo. I don't want to repeat the long story here, so I'll give the short one. The IJG JPEG is at version 9. Then libjpeg-upstream, Fedora, Debian, ... all will use it with .so.62 with 2 additional symbols, jpeg_mem_{dest,src} So this is correct, you need to run emerge @preserved-rebuild to get rid of .so.8 IJG JPEG -> .so.9 + backwards compability librarary .so.62 libjpeg-turbo -> .so.62 and no need for backwards compability library SONAME stays same The difference is that jpeg-9 has SmartScale feature and libjpeg-turbo doesn't and never propably will have it as it's deemed not so important; if needed at all. So the jpeg related ebuilds are OK in Portage and yes indeed, you need to do the massive rebuild like "emerge @preserved-rebuild" or "revdep-rebuild --library libjpeg.so.8" or both If libjpeg-turbo had adapted SmartScale we'd be raising it also to .so.9, but they declined it. Now we are going back to the commonly supported .so.62 same way as Fedora with jpeg_mem_dest() and jpeg_mem_src() backported from later jpeg. There would have been a massive rebuild in any case, either for .so.9 or for .so.62 because .so.8 is basically dead and buried together with .so.7 how does "bumping" #define JPEG_LIB_VERSION 80 to #define JPEG_LIB_VERSION 62 make any sense? Seems to me they don't really know what they are doing. (In reply to Julian Ospald (hasufell) from comment #3) > how does "bumping" > > #define JPEG_LIB_VERSION 80 > > to > > #define JPEG_LIB_VERSION 62 > > make any sense? Seems to me they don't really know what they are doing. In libjpeg-turbo it was never _really_ JPEG_LIB_VERSION 80 because the 80 ABI was only pretended for partial SONAME compability. It never had the 80 ABI features like SmartScale (Comment #2) Everything seems solid to me. (In reply to Samuli Suominen from comment #4) > (In reply to Julian Ospald (hasufell) from comment #3) > > how does "bumping" > > > > #define JPEG_LIB_VERSION 80 > > > > to > > > > #define JPEG_LIB_VERSION 62 > > > > make any sense? Seems to me they don't really know what they are doing. > > In libjpeg-turbo it was never _really_ JPEG_LIB_VERSION 80 because the 80 > ABI was only pretended for partial SONAME compability. It never had the 80 > ABI features like SmartScale (Comment #2) > > Everything seems solid to me. But it was defined as "80" in the header. That doesn't really look solid to me and obviously breaks code checks. (In reply to Julian Ospald (hasufell) from comment #5) > But it was defined as "80" in the header. That doesn't really look solid to > me and obviously breaks code checks. Yes - there might be couple of broken version checks where they should check for >= 62 and instead of >= 80 and check for the jpeg_mem_{dest,src} separately like with AC_CHECK_LIB But it's all as according to plan ;-) |