Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 110174 - glibc update breaks xsane scanning
glibc update breaks xsane scanning
Product: Red Hat Linux
Classification: Retired
Component: sane-backends (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
: 110110 110906 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-11-15 21:59 EST by Robert M. Riches Jr.
Modified: 2007-04-18 12:59 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-01 15:33:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
from strace -f -o ... scanimage -L (5.51 KB, text/plain)
2003-11-21 14:40 EST, Robert M. Riches Jr.
no flags Details
with old glibc, strace -f -o with-old-glibc scanimage -L (289.51 KB, text/plain)
2003-11-22 20:29 EST, Robert M. Riches Jr.
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:043 normal SHIPPED_LIVE Updated SANE packages fix problem with shared libraries 2004-03-01 00:00:00 EST

  None (edit)
Description Robert M. Riches Jr. 2003-11-15 21:59:25 EST
Description of problem:
The latest glibc update appears to have broken USB scanners.
Both Jacob Heider and I have seen similar symptoms.  (See
newsgroups linux.redhat on Nov. 15 if you need verification
of Jacob's situation.)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. have a working USB scanner configuration using an
   HP ScanJet 6300C.

2. update to glibc 2.3.2-4.80.8.

3. (optionally reboot for good measure)

4. try to run xsane.
Actual results:
"No devices available"

Expected results:
Xsane should find the scanner and use it.

Additional info:
sane-find-scanner finds it.  'scanimage --list-devices'
does not.  /dev/usb/scanner0 is o+rw as normal.  'rpm -qA'
shows no significant changes from before the update. 
/etc/sane.d/hp.conf is o+r and has correct contents, same
as before the update.  lsusb finds the scanner, looks normal.
There is no change when I power cycle the scanner, unplug
and then replug the USB cable, and rmmod and then modprobe
the 'scanner' module.  /var/log/messages show scanner.c
attaching to scanner0, as normal.

One thing I have not _noticed_ seeing before in
/var/log/messages is /etc/hotplug/usb.agent "setting usbcam
for USB product 3f0/601/100", which is the scanner.

I'm using stock RHL 8.0 plus all updates as of Nov. 15.

Again, a second person has confirmed in newsgroup
linux.redhat that he sees similar (but slightly different)
Comment 1 Michael 2003-11-16 12:42:49 EST
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).
Comment 2 Ulrich Drepper 2003-11-20 13:03:37 EST
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.
Comment 3 Robert M. Riches Jr. 2003-11-21 14:40:49 EST
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 ...).
Comment 4 Robert M. Riches Jr. 2003-11-21 14:54:14 EST
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.
Comment 5 Robert M. Riches Jr. 2003-11-22 20:29:58 EST
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.
Comment 6 Jakub Jelinek 2003-11-23 05:38:00 EST
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
Comment 7 Robert M. Riches Jr. 2003-11-24 19:15:30 EST
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.
Comment 8 Jakub Jelinek 2003-11-25 09:37:59 EST
*** Bug 110906 has been marked as a duplicate of this bug. ***
Comment 9 Tim Waugh 2003-12-03 07:00:07 EST
This seems to affect 7.3, 8.0 and 9.
Comment 10 Jakub Jelinek 2003-12-03 07:02:42 EST
Probably not 7.3, because I haven't touched 7.3 ldconfig, just 8.0/9.
Comment 11 Tim Waugh 2003-12-03 08:12:50 EST
Okay.  Robert, here is an experimental fixed package for 8.0.  Could
you please verify that it fixes the problem for you?

Comment 12 Robert M. Riches Jr. 2003-12-03 13:30:51 EST
I will download and try it at my earliest opportunity.
Best case would be this evening or tomorrow afternoon.
Comment 13 Robert M. Riches Jr. 2003-12-03 22:02:53 EST
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?
Comment 14 Tim Waugh 2003-12-04 12:22:10 EST
Has to go through QA first, but yes I hope this will be released as an
official update.
Comment 15 Tim Waugh 2003-12-23 10:31:56 EST
*** Bug 110110 has been marked as a duplicate of this bug. ***
Comment 16 Tim Waugh 2003-12-23 10:35:37 EST
The solution used in 1.0.8-5.3 was not the best one available.  Please
try this replacement:


and please let me know that it still keeps the problem fixed.
Comment 17 Robert M. Riches Jr. 2003-12-23 18:56:49 EST

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
Comment 18 Tim Waugh 2003-12-24 04:45:33 EST
Please try:


which really should fix the problem.  Sorry about that.
Comment 19 Robert M. Riches Jr. 2003-12-27 17:30:42 EST
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.
Comment 20 Daniel F. Dickinson 2003-12-31 19:59:47 EST
I can test 8.0 stuff if any more is created.
Comment 21 Tim Waugh 2004-01-02 08:50:20 EST
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.

Comment 23 Robert M. Riches Jr. 2004-01-02 17:08:18 EST
The 1.0.8-5.6 packages for RHL 8.0 from comment #21
appear to work for me.  Thanks!
Comment 24 Daniel F. Dickinson 2004-01-03 22:32:11 EST
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).
Comment 25 D. Hugh Redelmeier 2004-01-23 03:52:44 EST
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.
Comment 26 Robert M. Riches Jr. 2004-01-23 14:10:49 EST
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,

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.
Comment 27 Tim Powers 2004-03-01 15:33:05 EST
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.

Comment 28 Frank Schmidt 2004-03-04 15:58:49 EST
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:


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>>
Comment 29 Tim Waugh 2004-03-05 12:20:55 EST
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.
Comment 30 Robert M. Riches Jr. 2004-03-06 11:59:51 EST
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.

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