Bug 110174 - glibc update breaks xsane scanning
Summary: glibc update breaks xsane scanning
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sane-backends
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
: 110110 110906 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-16 02:59 UTC by Robert M. Riches Jr.
Modified: 2007-04-18 16:59 UTC (History)
7 users (show)

Clone Of:
Last Closed: 2004-03-01 20:33:05 UTC

Attachments (Terms of Use)
from strace -f -o ... scanimage -L (5.51 KB, text/plain)
2003-11-21 19:40 UTC, 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-23 01:29 UTC, 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 05:00:00 UTC

Description Robert M. Riches Jr. 2003-11-16 02:59:25 UTC
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 17:42:49 UTC
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 18:03:37 UTC
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 19:40:49 UTC
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 19:54:14 UTC
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-23 01:29:58 UTC
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 10:38:00 UTC
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-25 00:15:30 UTC
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 14:37:59 UTC
*** Bug 110906 has been marked as a duplicate of this bug. ***

Comment 9 Tim Waugh 2003-12-03 12:00:07 UTC
This seems to affect 7.3, 8.0 and 9.

Comment 10 Jakub Jelinek 2003-12-03 12:02:42 UTC
Probably not 7.3, because I haven't touched 7.3 ldconfig, just 8.0/9.

Comment 11 Tim Waugh 2003-12-03 13:12:50 UTC
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 18:30:51 UTC
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-04 03:02:53 UTC
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 17:22:10 UTC
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 15:31:56 UTC
*** Bug 110110 has been marked as a duplicate of this bug. ***

Comment 16 Tim Waugh 2003-12-23 15:35:37 UTC
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 23:56:49 UTC

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 09:45:33 UTC
Please try:


which really should fix the problem.  Sorry about that.

Comment 19 Robert M. Riches Jr. 2003-12-27 22:30:42 UTC
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 2004-01-01 00:59:47 UTC
I can test 8.0 stuff if any more is created.

Comment 21 Tim Waugh 2004-01-02 13:50:20 UTC
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 22:08:18 UTC
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-04 03:32:11 UTC
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 08:52:44 UTC
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 19:10:49 UTC
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 20:33:05 UTC
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 20:58:49 UTC
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 17:20:55 UTC
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 16:59:51 UTC
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.