Bug 888459 - Epson iscan broken since F17
Epson iscan broken since F17
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libpng (Show other bugs)
21
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Petr Hracek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-18 13:21 EST by Oliver Sampson
Modified: 2016-02-27 11:57 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 04:36:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Oliver Sampson 2012-12-18 13:21:02 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):
libpng-1.5.10-1.fc17.x86_64
libpng-compat-1.5.10-1.fc17.x86_64
libpng-1.5.10-1.fc17.i686
libpng-devel-1.5.10-1.fc17.x86_64
libpng-compat-1.5.10-1.fc17.i686


How reproducible:
Always.

Steps to Reproduce:
1. Install iscan on F17
2. Try to scan
3. See error
  
Actual results:
An error message

Expected results:
libpng-compat to provide the necessary calls to the application for operation.

Additional info:
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:
libpng-1.5.10-1.fc17.x86_64
libpng-compat-1.5.10-1.fc17.x86_64
libpng-1.5.10-1.fc17.i686
libpng-devel-1.5.10-1.fc17.x86_64
libpng-compat-1.5.10-1.fc17.i686

iscan-network-nt-1.1.0-2.x86_64
iscan-data-1.20.0-1.noarch
iscan-2.29.1-5.usb0.1.ltdl7.x86_64
Comment 1 Oliver Sampson 2012-12-18 13:25:31 EST
The scanner and iscan work fine in F16. Here are the pacakges associated with it:

libpng-debuginfo-1.2.49-1.fc16.i686
libpng-1.2.49-1.fc16.i686

iscan-network-nt-1.1.0-2.i386
iscan-2.28.1-3.i386
iscan-data-1.13.0-1.noarch
Comment 2 Tom Lane 2012-12-18 13:34:11 EST
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.
Comment 3 Tom Lane 2012-12-18 14:05:13 EST
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)
Comment 4 Oliver Sampson 2012-12-18 14:24:38 EST
Hi Tom,
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.
Comment 5 Tom Lane 2012-12-18 15:45:23 EST
(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.
Comment 6 Oliver Sampson 2012-12-19 02:53:25 EST
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:

ldd /usr/bin/iscan
        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)
        /lib64/ld-linux-x86-64.so.2 (0x00000039ed400000)
        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)
Comment 7 Tom Lane 2012-12-19 11:09:13 EST
(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.
Comment 8 Oliver Sampson 2012-12-19 11:38:06 EST
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.
Comment 9 Tom Lane 2012-12-19 12:24:31 EST
(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.
Comment 10 Fedora Admin XMLRPC Client 2013-05-14 09:50:33 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Fedora End Of Life 2013-07-03 22:32:27 EDT
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.
Comment 12 Fedora End Of Life 2013-08-01 04:36:19 EDT
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.
Comment 13 Andre Robatino 2015-02-01 05:09:05 EST
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".
Comment 14 Andre Robatino 2015-02-03 03:28:47 EST
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.
Comment 15 Andre Robatino 2015-03-11 08:08:38 EDT
(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.)
Comment 16 maarten 2016-01-23 13:33:06 EST
The tool works if you use it as a plug-in for GIMP

File->Create->Scanning (iscan)

Using the tool stand-alone causes the same 'disk space error.
Comment 17 Dan LaManna 2016-02-27 11:57:44 EST
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.

Note You need to log in before you can comment on or make changes to this bug.