Red Hat Bugzilla – Bug 888459
Epson iscan broken since F17
Last modified: 2016-02-27 11:57:44 EST
Description of problem:
Using any recent version of the iscan packages from the EPSON or now defunct Avasys.jp sites is not possible in F17 due to a library incompatibility.
When running iscan and scanning (preview works fine), the following error is written to the console:
libpng warning: Application built with libpng-1.2.31 but running with 1.5.10
and a dialog error "There is not enough disk space for operation" despite hundreds of gigs being free.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install iscan on F17
2. Try to scan
3. See error
An error message
libpng-compat to provide the necessary calls to the application for operation.
I have the libpng-compat package installed. I would think that this package would be responsible for the obsolete calls that are failing in F17.
Here are the packages installed as I have them:
The scanner and iscan work fine in F16. Here are the pacakges associated with it:
It seems much more likely that this is iscan's fault than libpng's. I'm suspecting it's doing dynamic loading of the library and picking the wrong library version. (It might be interesting to remove libpng-devel, so that the unversioned "libpng.so" symlink is no longer there, and see if the behavior changes.)
I can't really help you with non-Fedora software; you need to go to the iscan authors to resolve this.
Wups, sorry, did not mean to change component on this bug (was looking for iscan and didn't find it, but evidently fat-fingered the menu selection)
Well, I didn't really expect help with the Epson software, per se, but more with the library linking part, especially with the compatibility part. I'm surprised that backward compatibility is broken.
I see there's something called libpng10 and libpng-static. Are those something that could help here?
I just uninstalled libpng-devel to see if that would help, but it gives the same error.
(In reply to comment #4)
> Well, I didn't really expect help with the Epson software, per se, but more
> with the library linking part, especially with the compatibility part. I'm
> surprised that backward compatibility is broken.
There were no reports of such breakage among the hundreds of libpng-using packages in Fedora, so I think iscan is doing something out of spec. I don't know what though; the most obvious theory is that it was relying on the unversioned libpng.so symlink, and we seem to have eliminated that one.
You might try "ldd" on the iscan executable(s) to see whether it shows any dependency on libpng, and if so what the details are.
I'm starting to get a bit out of my area of expertise here, so a bit more handholding then normal may be required. :-)
ldd /usr/bin/iscan | grep -i libpng
libpng15.so.15 => /lib64/libpng15.so.15 (0x00000039f3400000)
Does that tell us anything useful?
The whole shebang:
linux-vdso.so.1 => (0x00007fffdc551000)
libesmod.so.2 => /lib64/libesmod.so.2 (0x0000003030c00000)
libltdl.so.7 => /lib64/libltdl.so.7 (0x0000003a02800000)
libgtk-x11-2.0.so.0 => /lib64/libgtk-x11-2.0.so.0 (0x0000003cbb600000)
libgdk-x11-2.0.so.0 => /lib64/libgdk-x11-2.0.so.0 (0x0000003cbb200000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003cb7800000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003cb8000000)
libsane.so.1 => /lib64/libsane.so.1 (0x0000003cba400000)
libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00000039fa000000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00000039fa400000)
libm.so.6 => /lib64/libm.so.6 (0x00000039eec00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000039f2000000)
libc.so.6 => /lib64/libc.so.6 (0x00000039ed800000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000039ee000000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039edc00000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003cb7000000)
libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x0000003cb7c00000)
libX11.so.6 => /lib64/libX11.so.6 (0x00000039f1800000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00000039f7400000)
libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x0000003cb9400000)
libcairo.so.2 => /lib64/libcairo.so.2 (0x00000039f5c00000)
libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x0000003cb9c00000)
libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x0000003cb8800000)
libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x0000003cb7400000)
libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x0000003cb8400000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00000039f4800000)
libXext.so.6 => /lib64/libXext.so.6 (0x00000039f1c00000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x00000039f2400000)
libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00000039f2c00000)
libXi.so.6 => /lib64/libXi.so.6 (0x00000039f3c00000)
libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00000039f3000000)
libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00000039f5800000)
libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00000039f6400000)
libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00000039f6000000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x0000003cb6c00000)
librt.so.1 => /lib64/librt.so.1 (0x00000039ee400000)
libffi.so.5 => /lib64/libffi.so.5 (0x00000039f0400000)
libv4l1.so.0 => /lib64/libv4l1.so.0 (0x000000323ce00000)
libieee1284.so.3 => /lib64/libieee1284.so.3 (0x0000003234e00000)
libtiff.so.3 => /lib64/libtiff.so.3 (0x0000003eea800000)
libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00000039fc400000)
libgphoto2.so.2 => /lib64/libgphoto2.so.2 (0x0000003248800000)
libgphoto2_port.so.0 => /lib64/libgphoto2_port.so.0 (0x00000039f9800000)
libexif.so.12 => /lib64/libexif.so.12 (0x0000003248400000)
libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x0000003a01800000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00000039f4400000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00000039f1400000)
libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00000039f6800000)
libpng15.so.15 => /lib64/libpng15.so.15 (0x00000039f3400000)
libz.so.1 => /lib64/libz.so.1 (0x00000039ee800000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00000039ef000000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00000039ef800000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00000039f3800000)
libv4l2.so.0 => /lib64/libv4l2.so.0 (0x0000003242000000)
libXau.so.6 => /lib64/libXau.so.6 (0x00000039f1000000)
libv4lconvert.so.0 => /lib64/libv4lconvert.so.0 (0x000000323fe00000)
(In reply to comment #6)
> ldd /usr/bin/iscan | grep -i libpng
> libpng15.so.15 => /lib64/libpng15.so.15 (0x00000039f3400000)
> Does that tell us anything useful?
Well, that's just weird, because this says that the application was hard-linked against libpng 1.5. There is no way that this executable could have worked at all on Fedora 16, because F16 didn't supply libpng 1.5. Perhaps the installation process for iscan tries to recompile (or at least relink) iscan, and does it incorrectly?
Anyway, what it looks like at this point is that iscan was compiled against libpng 1.2 headers (so that it's passing an "I'm compatible with 1.2" flag to libpng), but it is now linked against libpng 1.5. This is an application build error that I can't do anything about. You'll need to complain to the iscan authors.
Actually on F16 it's
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4c784000)
(I still have the laptop running F16 available.)
They are two different versions.
I previously tried the earlier version of iscan on f17, but it also didn't work, but I don't remember the reason why. I can try to nail that down, if it'd help.
(In reply to comment #8)
> They are two different versions.
Ah, that explains that part. Nonetheless, this build is broken, and could never have worked on any distro anywhere, because the version compatibility check is something that libpng does standardly. There's something messed-up about the build process they're using for iscan.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
Same issue with F21: "libpng warning: Application built with libpng-1.2.31 but running with 1.6.10" and again, the false message "There is not enough disk space for operation".
By the way, I sent a message to Epson support concerning this problem, and they closed the ticket twice, once after I reopened it. They basically said that all they have is what's on their site now, and it was pretty clear they have no interest in fixing this.
(In reply to Oliver Sampson from comment #4)
> I see there's something called libpng10 and libpng-static. Are those
> something that could help here?
F21 has the libpng12 package, and I was trying to see if there was a way to force iscan to make use of it. One person claimed in http://forums.fedoraforum.org/showpost.php?p=1625519&postcount=11 that they did so with
env LD_PRELOAD=/usr/lib64/libpng12.so.0 /usr/bin/iscan
but that does not work for me. (Same error.)
The tool works if you use it as a plug-in for GIMP
Using the tool stand-alone causes the same 'disk space error.
I encountered this on Fedora 23, running libpng 1.6.19.
Neither Andre or maarten's advice worked for me, but combining them did:
env LD_PRELOAD=/usr/lib64/libpng12.so.0 gimp - Then using the File->Create->Scanning from Gimp worked.