[sane-devel] minor: libusb not recognized

Tue Mar 30 21:42:09 BST 2004

Thank everyone of you for your enthusiastic and rapid help ... but I didn't 
want to launch any troll ;-)

as for my libusb issue, it was my fault: i'm a gentoo linux user and I didn't 
know the existence of a usb flag (needed to compile optional usb support).

Henning:
here's my sane-find-scanner's output:  
"
 # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a SCSI driver for your SCSI adapter.
  # Also you need support for SCSI Generic (sg) in your operating system.
  # If using Linux, try "modprobe sg".

found USB scanner (vendor=0x03f0, product=0x0a01, chip=GL646_HP?) at 
libusb:005:002
found USB scanner (vendor=0x046d, product=0x0840) at libusb:004:004
found USB scanner (vendor=0x06b9, product=0x4061) at libusb:003:002
  # Your USB scanner was (probably) detected. It may or may not be supported 
by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Scanners connected to the parallel port or other proprietary ports can't 
be
  # detected by this program.

  # You may want to run this program as root to find all devices. Once you
  # found the scanner devices, be sure to adjust access permissions as
  # necessary.
"
which is quite expectable since I entered manually my scanner's ids in 
genesys.conf

but I guess I missed something because first, the other supported scanners 
appear in the list (I have some other devices at the mentioned addresses).
and moreover, here are sane utilities outputs:

scanimage:
"
scanimage genesys:libusb
scanimage: no SANE devices found
"

xscanimage:
"
xscanimage genesys:libusb
xscanimage: relocation error: /usr/lib/sane/libsane-genesys.so.1: undefined 
symbol: sanei_usb_init
"

thank you for your advices, julien

Le mardi 30 Mars 2004 23:31, Enrico Weigelt a écrit :
> * Henning Meier-Geinitz <henning at meier-geinitz.de> [2004-03-30 20:13:29
> +0200]:
>
> <snip>
>
> > We only use autoconf (and autoheader, aclocal) to generate configure
> > from configure.in and acinclude.m4 and to generate
> > include/sane/config.h forom config.h.in.
>
> well, than just autoconf - where's the difference ?! ;-)
>
> <snip>
>
> > Do all bourne-shell "compatible" shells support these features?
>
> IMHO.
>
> > Does it really matter how the code that is created by autoconf look like?
>
> yes. there's almost no day where I'm not forced to look at some configure
> script and fix some nasty stuff ...
>
> autoconf produces really unmaintainable code.
>
> <snip>
>
> > > well, I'd like to have a simple (machine readable) file, which exactly
> > > describes what modules can be built from the package, which optional
> > > features the may have and what dependencies they all have.
> >
> > I see. In my opinion that's job for package maintainers. While we could
> > provide some hooks (like --without-frontends --without-tools) I think
> > the details are really up to the different package maintainers.
>
> Well, if we'd provide all these information, the package maintainers just
> have to select what modules + features they wanna have and let the machine
> do all the rest of the work. The current way, where the maintainer has
> to do very much things manually (i.e. selecting single files for
> packages,etc) is just an enormous resource wastal.
>
> If all packages would provide such machine readable build information,
> the job of the package maintainer itself would be (almost) obsolete ;-)
>
> <snip>
>
> > > those backends which 're using libusb then provide the optional feature
> > > "use-libusb" (or perhaps some better name...). if the usb access code
> > > of these backends resides in a common lib,
> >
> > It's a common part of code but that part is linked into the backends
> > themselves. No extra usb lib.
>
> well, then a static linked lib ?
> there's no real conceptional difference between dynamic and static linked
> libraries - just quest of one setting ...
>
> <snip>
>
> > > then just this lib would provide
> > > this feature. in the documentation we'd give a note, that
> > > linux-2.6-users should try this feature if they dont have
> > > /dev/usbscanner (it seems that 2.6 doesnt have usb scanner drivers
> > > anylonger)
> >
> > It's true that Linux 2.6 doesn't have a kernel scanner driver any more.
> > As some features don't work with the kernel scanner driver anyway,
> > there is no reason to not use libusb on every system in my opinion.
> > There is even one backend (sm3600) which doesn't work at all without
> > libusb.
>
> Well, perhaps some people do not want libusb, so it should be a optional
> feature, but perhaps enabled per default.
>
> btw: for each feature there should be an flag for explicitly enabling
> or disabling this, and also there should be a option for dumping the
> active features and their dependencies.
>
> <snip>
>
> > > * list all modules in a package, their features and all their
> > > dependencies * build a list of modules w/ specified features
> > >   (also support for chroot-builds + crosscompile)
> > > * spit out a list of files and their classes for each module
> >
> > Looks like package maintainer's stuff for me.
>
> ... like I already said .. better let the machine do it by itself.
>
> > Also it only makes sense if every software use the same format?
>
> Well, that's where I want to go to (I'm trying this in a dozen of projects)
> But someone has to make the first step :)
>
> <snip>
>
> > > > > btw: the current libusb is broken - it's libfiles' names are
> > > > > missing .so.
> > > >
> > > > Which current libusb?
> > >
> > > 0.1.8
> >
> > Ah, you are right. Strange.
>
> it also produces a wrong libusb.la file, so building sane-backends makes
> also trouble on compiling ...
>
>
>
> cu
> --
> ---------------------------------------------------------------------
>  Enrico Weigelt    ==   metux IT services
>
>   phone:     +49 36207 519931         www:       http://www.metux.de/
>   fax:       +49 36207 519932         email:     contact at metux.de
>   cellphone: +49 174 7066481
> ---------------------------------------------------------------------
>    -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
> ---------------------------------------------------------------------