Bug 110174

On RHL9 the glibc update seems to break the cmd line "scanimage", but
xsane still works.  (I've got an Epson 1240U.)

This is also being tracked under bug #110110 (RHL9/sane-backends).

Run scanimage with

  strace -f -o SOMEFILE scanimage PARAMS...

with the old and the new glibc so that we can see the difference.

The device handling is nothing glibc does itself.  So it can be only a
problem with scanimage using some interface incorrectly.

Created attachment 96129 [details]
from strace -f -o ... scanimage -L

This is the output from strace -f -o with-new-glibc scanimage -L.
I see an item in a related report about a DEBUG_DLL environment
variable.  I'll attach that too.  I'll downgrade glibc and run
the strace of scanimage at the next opportunity (hopefully within
a day or three or ...).

I tried setting environment variable SANE_DEBUG_DLL
to 4 and running scaminage, but it didn't produce
any additional output than without the variable.
Maybe that variable is only active in RHL 9.

Created attachment 96139 [details]
with old glibc, strace -f -o with-old-glibc scanimage -L

This is the output of 'strace -f -o with-old-glibc scanimage -L'
with the old glibc, glibc-2.3.2-4.80.6.  Scanning works fine.

One obvious difference is the path where libsane.so.1 is found.
The two paths have different contents.	There is no mismatch
found when doing 'rpm -V' on any *sane* package.

That looks like sane-backends bug.  Having two different libsane.so.1
libraries with different functionality in ld.so.cache is very bad idea.

What glibc-2.3.2-4.80.8 changed is the search order in ldconfig:
the old hjl's ldconfig searched first paths specified in ld.so.conf
and then the default (/lib and /usr/lib), while ldconfig in glibc used
to search the default ones first and then the ld.so.conf ones.
The latter has the serious drawback that /lib and /usr/lib really
couldn't be overrided.  glibc-2.3.2-4.80.8 changes things to how they
look in CVS glibc.

You can work around it by adding /lib and /usr/lib to the beginning
of /etc/ld.so.conf and rerunning ldconfig, but as I said, sane
should be fixed instead.

Looking at sane-backends in Fedora Core 1 (where ldconfig behaves
the same way as in glibc-2.3.2-4.80.8) there is no /usr/lib/sane/libsane.so.1
symlink.

The move to sane-backends sounds reasonable.  Thanks for the
suggested workaround.  I found one that IMHO is even more
precise (less global impact).  For xsane, scanimage, and
gimp (and any others I might run in to, make a script in
/usr/local/bin of the following form:

#!/bin/csh -f

set noglob
setenv LD_LIBRARY_PATH /usr/lib
exec /usr/bin/xsane $*

The run time overhead for this appears to be negligible.
Thanks again for the quick resolution--at least to the
workaround stage.

*** Bug 110906 has been marked as a duplicate of this bug. ***

This seems to affect 7.3, 8.0 and 9.

Probably not 7.3, because I haven't touched 7.3 ldconfig, just 8.0/9.

Okay.  Robert, here is an experimental fixed package for 8.0.  Could
you please verify that it fixes the problem for you?

ftp://people.redhat.com/twaugh/tmp/sane-backends-1.0.8-5.3.i386.rpm

I will download and try it at my earliest opportunity.
Best case would be this evening or tomorrow afternoon.

Best case worked out.  It seems to be working.  I can do
"/usr/lib/scanimage -L" and "/usrlib/xsane" and get the
expected or correct results.  Doing
"file `rpm -ql sane-backends`" shows the new package has
dropped the symlink to the v4l-related library and a ton
of .man files from /usr/share/doc.  Was the last omission
intentional?  (No answer needed.)

Is there any reason I should back out this experimental
package and revert to the workaround?

Will this package be released to production for 8.0?

Has to go through QA first, but yes I hope this will be released as an
official update.

*** Bug 110110 has been marked as a duplicate of this bug. ***

The solution used in 1.0.8-5.3 was not the best one available.  Please
try this replacement:

ftp://people.redhat.com/twaugh/tmp/sane-backends-1.0.8-5.4.i386.rpm

and please let me know that it still keeps the problem fixed.

Nope.

The new 5.4 package breaks it.  This new package brought
back /usr/lib/sane/libsane.so.1 as a symbolic link to
libsane-v4l.so.1.0.8, and the latter apparently only
looks for v4l devices, not USB (or other?) scanners.  I
reverted to the 5.3 package, and it works again.

(In a week or three, I plan to move to RHL 9, so I won't
be able to test more RHL 8.0 packages.  Of course, in a
week, EOL will make it irrelevant for 8.0, and EOL is
why I'm moving to RHL 9 until April, when I will have to
move to another distribution.  Don't know which it will
be: maybe Fedora, maybe something else, because I can't
afford $540 per year, especially for only a partial
distribution.)

Please try:

ftp://people.redhat.com/twaugh/tmp/sane-backends-1.0.8-5.5.i386.rpm

which really should fix the problem.  Sorry about that.

I hate to be the bearer of bad news, but this one failed
for me, too.  It appears something, likely one of the
post-install scripts, is creating /usr/lib/sane/libsane.so.1
as a symlink to libsane-v4l.so.1.0.8, and this causes the
problem, given the new ldconfig search policy in the new
glibc from back in November.

I can test 8.0 stuff if any more is created.

Oops.  Please try 1.0.8-5.6.  If you tried one of the experimental
fixes, please downgrade to the official 1.0.8-5.2 upgrade using 'rpm
-Uvh --oldpackage sane-backends-*1.0.8-5.6*' first.

ftp://people.redhat.com/twaugh/tmp/sane-backends-1.0.8-5.6.i386.rpm
ftp://people.redhat.com/twaugh/tmp/sane-backends-devel-1.0.8-5.6.i386.rpm

..and experimental packages for Red Hat Linux 9 are here:

http://cyberelk.net/tim/data/tmp/sane-backends-1.0.9-5.5.i386.rpm
http://cyberelk.net/tim/data/tmp/sane-backends-devel-1.0.9-5.5.i386.rpm

The 1.0.8-5.6 packages for RHL 8.0 from comment #21
appear to work for me.  Thanks!

This works for me, both for launching xsane directly and from
gimp-1.2.  (Using a script wrapper didn't like launching xsane from
gimp for some reason).

I experienced this problem with RHL8 and 9.  I found that the fix was
to the sane-backends rpm's postinstall script: eliminate /usr/lib/sane
from /etc/ld.so.conf.  (I see that this is the fix that Tim has
implemented, but I think that it is worth mentioning here.)

I wonder if the same bug is in Fedora Core 1.  The symlink in
/usr/lib/sane/libsane.so.1 is there, but no longer to libsane-v4l. 
/usr/lib/sane still appears in /etc/ld.so.conf, contrary to what
/usr/share/doc/xsane*/xsane.PROBLEMS specifies.  I don't have FC1 and
a scanner on the same system to test.

In case it helps cross-correlate any other observations,
my main machine is now running RHL 9, stock plus updates,
and here is what I see, with only the stock, official,
packages:

sane-find-scanner finds the scanner twice, as
/dev/usb/scanner0 and as libusb:002:002.

scanimage -L finds my BTTV card, dev/video0 but
not the scanner.

xsane finds both the scanner (once) and the BTTV card.

I use xsane, so I'm happy, for now.

An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-043.html

Hi, I am on Fedora CORE 1 Kernel 2.4.22-1.2166.nptl the rest is
upgrade to newest and greatest. My printer/scanner is HP PSC 2175. I
must say I went to Fedora since I had tremendous problems on Redhat
7.3.3, although eventually "xsane" works fine. Unfortunately, I cannot
upgrade security upgrades of this old kernel (==> kernel crashes, when
switching on printer)  

I have the exact problem as described in this error #110174. I tried
to follow the advice given in the Comments about this bug but to no
avail. The sane related installed packages are:

xsane-gimp-0.91-1
sane-frontends-1.0.11-3
sane-backends-devel-1.0.12-4
sane-backends-1.0.12-4
xsane-0.91-1
libsane-hpoj-0.90-19

I find my scanner with "sane-find-scanner"
found USB scanner (vendor=0x03f0, product=0x2b11) at libusb:001:005

However "scanimage -L" finds nothing. How to get it work>>

Frank, it's not clear what product or version you are running -- in
any case, it doesn't seem to be Red Hat Linux 8.0 or Red Hat Linux 9,
and if you are running Fedora Core 1 it is certainly a different
problem you are seeing.

Please file a separate bug report, including as much detail as you
can.  Thanks.

On RHL 9, I just updated to the just-released
sane-backends-1.0.9-5.5, and everything looks grand:
sane-find-scanner finds the scanner as /dev/usb/scanner0
and as libusb:002:003, scanimage -L finds both the BTTV
card and hp:/dev/usb/scanner0, and xsane finds both.

Tim, thanks for the update.