Summary: | Stable x86 media-gfx/povray-3.6.1 fails to run with libjpeg mismatch - stabilize 3.7? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bob Johnson <bob> |
Component: | Current packages | Assignee: | Joe Peterson (RETIRED) <lavajoe> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ssuominen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Build log
Steps taken to try to get 3.6.1 to pick up jpeg textures Build log for 3.6.1-r4 config.log for povray-3.6.1 with only 1 jpeglib.h header file located Build log for 3.7.0_rc3 povray-3.6.1-r4.diff |
Description
Bob Johnson
2011-09-10 06:15:55 UTC
Created attachment 286029 [details]
Build log
Thanks for the report! OK, what I have done is to "fix" 3.6.1 by having its configure script require libjpeg-6b (and not higher versions), and if it does not exist, it will use the included static libjpeg (and libtiff) instead. Unfortunately, this required me to bump the rev and mark it unstable, and since the older ebuild is broken, I removed it (so there is now no longer a stable version). I'll request stabilization of 3.7.0_rc3, even though it's an RC, since it's been around so long. This will be quicker than waiting 30 days to request 3.6.1-r5 stabilization. CCing both qa and security for this as the commit needs to be reverted. Instead you should remove the vulnerable copies of said bundled libraries, to ensure no headers from it are being used. OK, good security catch. If these are vulnerable, then we'll need to just get rid of this version, or simply leave -r4 as unstable (and not be able to request stabilizing), as there is no stable version of libjpeg-6b. If you agree, I will do the latter now. Please advise. (In reply to comment #4) > OK, good security catch. If these are vulnerable, then we'll need to just get > rid of this version, or simply leave -r4 as unstable (and not be able to > request stabilizing), as there is no stable version of libjpeg-6b. > > If you agree, I will do the latter now. Please advise. jpeg might be OK, but tiff has an track record wrt security. in any case I suspect the user has jpeglib.h somewhere in his system, possibly in /usr/local/include, installed by some 3rd party package out-of-portage causing the problem. or the system is in inconsistant state, and needs an `revdep-rebuild --library libjpeg.so.62` (In reply to comment #5) > (In reply to comment #4) > > OK, good security catch. If these are vulnerable, then we'll need to just get > > rid of this version, or simply leave -r4 as unstable (and not be able to > > request stabilizing), as there is no stable version of libjpeg-6b. > > > > If you agree, I will do the latter now. Please advise. > > jpeg might be OK, but tiff has an track record wrt security. > > in any case I suspect the user has jpeglib.h somewhere in his system, possibly > in /usr/local/include, installed by some 3rd party package out-of-portage > causing the problem. > > or the system is in inconsistant state, and needs an `revdep-rebuild --library > libjpeg.so.62` Here's what I get when I try those steps: ------ inara ~ # revdep-rebuild --library libjpeg.so.62 * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using libjpeg.so.62 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 100% ] * There are no dynamic links to libjpeg.so.62... All done. inara ~ # locate jpeglib.h /home/bjohnson/projects/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/jpeg-6b-r7/jpeg-6b/jpeglib.h /usr/include/jpeglib.h inara ~ # equery belongs /usr/include/jpeglib.h * Searching for /usr/include/jpeglib.h ... media-libs/libjpeg-turbo-1.1.1 (/usr/include/jpeglib.h) inara ~ # ------ There is no /usr/local/include directory. The gumstix header file is a local user cross-development project and is not sourced except from within the cross-development environment. As you can see, the system jpeglib.h header belongs to a portage tree build. If you still believe this is a problem with my system and not with the ebuild, I'd be happy to run other tests. Let me know. I have reverted the static lib change due to potential security issues. Also, I tried reading a JPEG file as a texture with version povray-3.6.1 and jpeg-8c installed, and it works on my end without the error reported by the submitter. Can the submitter verify that doing this (a JPEG texture) results in the error on his system? And see the above comment by Samuli Suominen - is it possible there is a rogue header file on your system? (In reply to comment #6) > inara ~ # locate jpeglib.h > /home/bjohnson/projects/gumstix/gumstix-oe/tmp/work/armv5te-angstrom-linux-gnueabi/jpeg-6b-r7/jpeg-6b/jpeglib.h > /usr/include/jpeglib.h > inara ~ # equery belongs /usr/include/jpeglib.h > * Searching for /usr/include/jpeglib.h ... > media-libs/libjpeg-turbo-1.1.1 (/usr/include/jpeglib.h) > inara ~ # > ------ > > There is no /usr/local/include directory. The gumstix header file is a local > user cross-development project and is not sourced except from within the > cross-development environment. As you can see, the system jpeglib.h header > belongs to a portage tree build. Are you *sure* the environment is clean and the cross-environment flags are not being exported to your user and/or portage user? Run env or export to find out. The error is just exactly what you'd get if an old copy of jpeglib.h is getting picked up. I've just seen this many times before, so sorry for pushing it. You could attach config.log here, perhaps it has insight of where the jpeglib.h is coming from. Assuming that is the problem... Not a problem Samuli, that was exactly my thought when I first encountered this issue. I repeated the steps I went through previously before I gave up and concluded (without hard evidence) that povray 3.6.1 was picking up its bundled jpeglib.h header even though the build log was stating differently. I've attached my debugging steps in the file povray361debugsteps.txt. I agree that povray *has* to be picking up the wrong .so or header somewhere, but I can't figure out where. When I tried building the distfile myself in a temporary directory, I saw that povray included its own libjpeg stuff in case it couldn't find a system version. However, the build logs indicate it is picking up the system library. When the unstable version built and ran, I concluded (perhaps incorrectly) that the povray 3.6.1 make system was broken (grabbing the internal header file), and punted the issue up to bugzilla. I've attached the build log for the 3.6.1 build. I don't need povray at the moment, so I'll keep 3.6.1 on my system for a bit in case anyone has other ideas. I have to admit, I'm totally befuddled by Joe being able to pick up jpgs successfully when I can't. Created attachment 288255 [details]
Steps taken to try to get 3.6.1 to pick up jpeg textures
Created attachment 288259 [details]
Build log for 3.6.1-r4
config.log from /var/tmp/portage/media-gfx/povray-3.6.1-r4/work/povray-3.6.1 Created attachment 288321 [details]
config.log for povray-3.6.1 with only 1 jpeglib.h header file located
Oh, that config.log. OK, I've uploaded it.
OK, I found some more time to look at this tonight. The problem appears to be this line in the configure script (line 15875): for pov_flags in "-malign-double" "-minline-all-stringops"; do The '-malign-double' compiler option causes the mismatch with the system jpeg library. I'm guessing that the jpeg library ebuild does not use this flag, and povray-3.6.1 does, and the resulting alignment/padding ends up different on my 32-bit system. When I build a local copy of povray with all the ebuild patches applied and the configure line changed to remove -malign-double: for pov_flags in "-minline-all-stringops"; do the code configures, compiles and runs just fine. I suspect Joe is running a 64-bit system, and that's why he doesn't see this issue. The configure script mentions that this option is ignored on 64-bit systems. If you want a patch file let me know. Since I don't know what removing 'align-double' might break, I'll let you devs sort out how you want to handle this. (In reply to comment #14) > OK, I found some more time to look at this tonight. The problem appears to be > this line in the configure script (line 15875): > > for pov_flags in "-malign-double" "-minline-all-stringops"; do Bob, interesting. I looked at povray-3.6.1 as well as povray-3.7.0, and both use this switch. I wonder why you are able to run 3.7.0, then - perhaps just luck. Do you have any insight into this? If this is truly the root of the issue, we should disable this switch in all versions of povray. (In reply to comment #15) > Bob, interesting. I looked at povray-3.6.1 as well as povray-3.7.0, and both > use this switch. I wonder why you are able to run 3.7.0, then - perhaps just > luck. Do you have any insight into this? If this is truly the root of the > issue, we should disable this switch in all versions of povray. OK, correction: on my 64-bit system, -malign-double is included in the compile flags for 3.6.1 but not for 3.7.0. The gcc man page says that this switch is enabled by default on 64-bit (not "rejected", as the povray configure file states), but this still would explain why both versions work for me (since including the switch would make no difference). Can you verify on your 32-bit system that you also see the -malign-double switch used when compiling 3.6.1 but not for 3.7.0? The configure logic is different for the two versions, even though they both include the switch in their logic. Created attachment 288377 [details]
Build log for 3.7.0_rc3
Sure. I re-keyworded povray and re-emerged. The build log is attached.
If you look at my 3.6.1 build log you can clearly see the -malign-double flag being used on the compiler command line. In my 3.7.0 build log -malign-double is nowhere to be found. I do believe align-double is the culprit on my system.
What I don't know is whether align-double was added for some other reason or if it was just premature optimization on the part of the POV build. I suspect the latter given that it has disappeared in 3.7.0 :-)
(In reply to comment #17) > If you look at my 3.6.1 build log you can clearly see the -malign-double flag > being used on the compiler command line. In my 3.7.0 build log -malign-double > is nowhere to be found. I do believe align-double is the culprit on my system. > > What I don't know is whether align-double was added for some other reason or if > it was just premature optimization on the part of the POV build. I suspect the > latter given that it has disappeared in 3.7.0 :-) Bob, thanks. Yeah, it appears that 3.7.0 only includes this switch if arch-specific optimizations are enabled, which they are not (both 3.7.0 ebuilds disable these). 3.6.1 does not disable optimizations. I'll attach an ebuild with these disabled. If you can try this and let me know if it fixes the problem for you, I'll put it in the tree as a new rev (it will not be marked stable, but at least the fix will be there). Created attachment 288391 [details, diff]
povray-3.6.1-r4.diff
That patch works Joe. The -malign-double is gone in the compiler command line, and the program correctly builds the jpg-textured test image I've been using. nice catch... Indeed! Good sloothing! |