icedtea6 trys to dlopen libjpeg.so.62, but cannot find it and crashes, recompile does not help. icedtea6 should depend on =jpeg-6 until this is fixed. Reproducible: Always Steps to Reproduce: 1.display jpeg in java app 2.run with icedtea6 3. strace (crashing part) [pid 24308] open("/usr/lib64/icedtea6/jre/lib/amd64/server/libjpeg.so.62", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 24308] open("/usr/lib64/icedtea6/jre/lib/amd64/libjpeg.so.62", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 24308] open("/usr/lib64/icedtea6/jre/lib/amd64/libjpeg.so.62", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 24308] open("/etc/ld.so.cache", O_RDONLY) = 10 [pid 24308] fstat(10, {st_mode=S_IFREG|0644, st_size=176230, ...}) = 0 [pid 24308] mmap(NULL, 176230, PROT_READ, MAP_PRIVATE, 10, 0) = 0x7fb98e674000 [pid 24308] close(10) = 0 [pid 24308] open("/lib64/libjpeg.so.62", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 24308] open("/usr/lib64/libjpeg.so.62", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 24308] munmap(0x7fb98e674000, 176230) = 0 [pid 24308] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
if compiled with jpeg-7, it wants to open libjpeg.so.62, but expects it to be jpeg-7 this happens when i copy a old jpeg-6 in the libpath: sun.awt.image.ImageFormatException: Wrong JPEG library version: library is 62, caller expects 70 at sun.awt.image.JPEGImageDecoder.readImage(Native Method) at sun.awt.image.JPEGImageDecoder.produceImage(JPEGImageDecoder.java:136) at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:264) at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:189) at sun.awt.image.ImageFetcher.run(ImageFetcher.java:153) createing a symlink works (libjpeg.so.62 -> libjpeg.so.7) if icedtea6 is compiled with jpeg-7
Symlinking is all wrong. If icedtea6 is a binary only package it should be using media-libs/jpeg-compat. || ( media-libs/jpeg-compat <media-libs/jpeg-7 ) If it's a source based package then it should be fixed and recompiled against jpeg-7 or someone should contact the person who created the binary package to do so.
yes, i know symlinking is wrong, but it's the only solution i have for now. and yes i'm talking about dev-java/icedtea6 from java overlay (source build, not binary dist, i'm on amd64)
*** Bug 284582 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > yes, i know symlinking is wrong, but it's the only solution i have for now. and > yes i'm talking about dev-java/icedtea6 from java overlay (source build, not > binary dist, i'm on amd64) Then it's most likely using bundled and possibly internal jpeg headers and then tries to use system library causing the conflict. Can you post a link to the source tree?
Created attachment 203792 [details] icedtea6 ebuild
overlay: svn+http://overlays.gentoo.org/svn/proj/java/java-overlay/ package: dev-java/icedtea6-1.5.2 ebuild attached
icedtea6-bin ebuild's in tree fixed
didn't try the bin package, but icedtea6-1.6.1 has the same behavior.
Got the testcase, please?
Created attachment 206803 [details] small java program to test image loading
Thanks, reproduced and hopefully found the source of problem. Building patched version...
icedtea6-1.6.1-r1 in java-overlay is fixed, icedtea6-bin will follow
icedtea6-1.6.1 fixed
hmm ... i don't see icedtea6-1.6.1-r1 or changes in icedtea6-1.6.1 in java-overlay (revision 7933)
Forgot to commit, sorry. Try now.
And here I thought it was just me. Thanks. It shows up now.
it's working now, thx
