Summary: | media-libs/sdl-image-1.2.10 fails to open jpg images w/ media-libs/jpeg-8 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Petr Zima <zima> |
Component: | [OLD] Library | Assignee: | Gentoo Games <games> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | kfm, nik, silvio.gerli, web |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Petr Zima
2010-02-16 15:56:48 UTC
That's probably a CANTFIX. revdep-rebuild works (on libs) by analyzing ldd output. If a lib is dlopen'ed, it can't be detected that way. Doesn't sound like a bug in sdl-image to me. I have done some debugging and the problem is an API/ABI mismatch. When there is jpeg-8 installed with the preserved libjpeg.so.7 then sdl-image rebuild uses headers of version 8 but the old .so of version 7. The old .so is dynamically loaded fine (no problem in dlopen/libtool/ldconfig as I suggested), but the exported functions of libjpeg explicitly check version (and also struct sizes etc.) passed by the caller and immediately fail since 80 != 70. Hence it is a kind of bug in sdl-image's configure, which should preferably find the right version of libjpeg.so which is compatible with the headers. Or at least the newer version would be imho a better guess than the older one. I stil dislike the idea of preserving the old .so.7 in jpeg-8 at all. However this problem might appear also for slotted versions of jpeg which is perfectly legimate configuration and so should be fixed. The problem here is that sdl-image determines jpeg library to link to by "ls /usr/lib/libjpeg.so.[0-9] | sort | sed 's/.*\/\(.*\)/\1/; q'" As long as libjpeg.so.7 is still there, it will be the result of this query. Only after it's removed can sdl-image be rebuilt correctly. Sounds like a bug in sdl-image to me, bad logic, likely only designed for systems with one libjpeg.so.X installed while it's perfectly valid to have old ABI available too If it's really doing ls /usr/lib/libjpeg.so.[0-9] | sort | sed 's/.*\/\(.*\)/\1/; q' Then maybe it should be reversed to ls /usr/lib/libjpeg.so.[0-9] | sort -r | sed 's/.*\/\(.*\)/\1/; q' The -r switch being the key here i vaguely recall that just about all the main SDL projects have similar brain dead libjpeg.so lookups. i never cared in the past because it looked like libjpeg.so.62 (jpeg-6b) was going to be the last version ever ... *** Bug 305735 has been marked as a duplicate of this bug. *** gives me chills but I put the sort -r hack in there for sdl-image-1.2.10-r1.ebuild. It works as expected but the whole find_lib function in configure looks pretty evil to me. *** Bug 307087 has been marked as a duplicate of this bug. *** *** Bug 291858 has been marked as a duplicate of this bug. *** in games-action/wop show this error INFO: Theme background is '(null)' ERROR: Video::loadImage: Couldn't load image '/usr/share/games/wop/images/mapstuff/background/dark_earth.jpg' after update sdl-image-1.2.10-r1 solve this problem Latest revs of all the core sdl libraries link against the libraries instead of using dlopen with the interesting configure-time library-finding shell code. Should work better over time now. |