The current x86 stable version of povray requires the old libjpeg 6.2 library. As the jpeg library is now at 8, povray exits with this message whenever trying to access jpegs: "Possible Parse Error: jpeglib: JPEG parameter struct mismatch: library thinks size is 484, caller expects 488" Reproducible: Always Steps to Reproduce: 1.Compile povray-3.6.1 on stable x86 system 2.Run it 3.Problem The unstable x86 povray version (currently media-gfx/povray-3.7.0_rc3) compiles and correctly renders the same test files that produced the above JPEG error on the 3.6.1 version. This problem has apparently been around for a while, here's a posting in the French section of the forum: http://forums.gentoo.org/viewtopic-t-834204-start-0.html As my French doesn't extend beyond 'Bonjour', I'm not sure what resolution, if any, was found there. A quick glance at the build log shows this: checking for library containing jpeg_std_error... -ljpeg checking jpeglib.h usability... yes checking jpeglib.h presence... yes checking for jpeglib.h... yes checking for libjpeg version >= 6b... 8, ok So it seems to be picking up the system library at build time. lddtree shows the povray binary links to the system (ver 8) libjpeg. It must either be linking to the old jpeg6.2 header included in the build source (although I don't see it doing so in the build log) or there's some hard-coded dependencies somewhere in the code. Simplest fix is probably just to stabilize a later version of povray. My emerge --info for those who care: Portage 2.1.10.11 (default/linux/x86/10.0, gcc-4.4.5, glibc-2.12.2-r0, 2.6.39-gentoo-r3 i686) ================================================================= System uname: Linux-2.6.39-gentoo-r3-i686-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-gentoo-2.0.3 Timestamp of tree: Fri, 09 Sep 2011 17:15:01 +0000 app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.1-r1, 3.1.3-r1 dev-util/cmake: 2.8.4-r1 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.8.3-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 2.6.36.1 (virtual/os-headers) sys-libs/glibc: 2.12.2 Repositories: gentoo science x-portage ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA vmware" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=prescott -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en_US" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/science /usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X a52 aac acl alsa amr apache2 berkdb bluetooth bzip2 cairo cdda cli consolekit cracklib crypt css cups curl cxx dbus doc dri dts dv dvd dvdr dvi encode examples exif ffmpeg flac fontconfig fortran gcj gd gdbm gif gimp graphviz gstreamer gtk guile handbook hddtemp iconv icu id3tag ieee1394 ipv6 jack jadetex java jbig joystick jpeg jpeg2k kpathsea ladspa lcms libsamplerate libv4l2 lm_sensors loop-aes mad mbox midi mikmod mmx mng modules mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin odbc ogg openal opengl openmp pam pcre pdf perl png policykit ppds pppd python qt3support quicktime raw readline rtc samba scanner sdl semantic-desktop session sox spell sse ssl svg sysfs t1lib tcl tcpd templates theora threads tiff tk truetype udev unicode usb v4l v4l2 vcd vorbis win32codecs wmf x86 xanim xattr xine xinerama xml xorg xpm xulrunner xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgid dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="canon" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev vmmouse wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_US" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev intel radeon vesa vmware nv nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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!
