I too had some issues getting all the SANE pieces to compile and find all the libraries under Solaris 8 (Sparc) using gcc 3.1. I Installed GIMP and image libraries from Sun's companion CD into /opt/sfw and wanted everything SANE to live there too. I also wanted the pnm backend and GIMP plugins ...
Sane Backend ... ./configure --prefix=/opt/sfw --enable-pnm-backend Sane Frontend ... CPPFLAGS="-I/opt/sfw/include" LDFLAGS="-L/opt/sfw/lib" ./configure --prefix=/opt/sfw Xsane ... CPPFLAGS="-I/opt/sfw/include" LDFLAGS="-L/opt/sfw/lib" ./configure --prefix=/opt/sfw There may have been an easier way to do this but this gave me the results I desired. Kipland Iles >From: Henning Meier-Geinitz <[email protected]> >To: [email protected] >Subject: Re: [sane-devel] scanimage problem / sane 1.0.8 / Epson / Solaris >8 (x86) >Date: Thu, 27 Jun 2002 18:40:44 +0200 > >Hi, > >On Thu, Jun 27, 2002 at 04:12:52PM +0100, Ed Randall wrote: > > One thing that was immediately apparent by setting > > SANE_DEBUG_SANEI_SCSI=255 was that it was looking for devices other > > than my Epson scanner, > >That's expected behaviour. If you also enable SANE_DEBUG_DLL=255, you >can see which backend is currently active. > > > the first it tried was /dev/camera... > >That should be ok. It's used by the dmc backend as a link to the >actual SCSI camera. Is this file used for anything else on Solaris? > > > a > > bit more investigation led me to edit dll.conf and comment out > > all those extra devices that are enabled by default. > >That's usually a good idea to avoid running into bugs of other >backends. Currently I don't know of such a bug, however. > > > This didn't fix the problem(s) though, in to the bargain I started > > getting very frequent SIGSEGV's. > >Removing backends from dll.conf resulted in segfaults? That's >interesting :-) > > > I made some debugging code changes to epson.c (see "diff -c" patch > > output below) to debug data buffers in a controlled-length hex dump > > instead of 1 byte per line. There was some code already there to > > do that true, but > > (a) it didn't do it exactly the way I needed, and was slightly > > complicated, I couldn't see immediately exactly what it was doing, and > > (b) it needed to be in a function so I could use it from a couple > > of places. You could hopefully move it out into a more general > > file and use it elsewhere now. > >Yes, maybe similar can be added to the sanei_debug stuff. However, be >careful not to use printf/fprintf directly because you never know, if >you are on a network connection (running saned). > > > I think there's a lot of non-intrusive interaction going on between > > the various backends that are enabled by default, the initial default > > installation maybe needs to be a bit more careful on the settings for > > the sake of naive lazy users who just want to scan and not be > > software configuration experts ;-) > >Generally, all SCSI backends send a SCSI inquiry command to the >devices they check. That's either /dev/scanner or any device manually >configured. This shouln't harm any device. And the advantage is, you >don't need to be software configuration experts and only set one link >(/dev/scanner). > >It would be even easier if there was a way to search for a specific >SCSI device on Solaris. Then the "scsi ..." directives in the config >files wouldn't only work on Linux (and BSD?) and the user wouldn't >even have to set the link. > >If there is any problem with a backend's autodection on Solaris, feel >free to comment on it. > > > A couple of side issues I encountered during installation - the > > sane-config script that gets installed is no longer compatible with > > the ./configure in xsane 0.86, lots of usage messages pop up. > >Hm? This doesn't happen here (with Linux). Can you investigate, what's >the problem? As far as I know, sane-config.in hasn't been changed >significantly. > > > Also it uses "echo -e $usage" in > > lots of places, this may work on Linux/Bash but it is not portable >/bin/sh > > behaviour for the Solaris nor the rest of the Unix world ;-) > >That's probably true. I'm not quite sure why this hasn't occured when >I testest *BSD, Solaris, AIX etc. Maybe I never tried the usage output. > > > Anybody who has tried installing gtk, glib and sane in a non-standard > > place (ie not /usr/local/bin) as I have will probably agree with me that > > the ./configure process for dependant applications has now become much >harder. > >You mean "since the XXX-config scripts exist"? That's wuite a long >time :-) > > > Whilst the XXX-config script is intended to report back locations of >critical > > parts, the ./configure seems unable to do the right thing - it can't >find the > > XXX-config script unless I put it on the path (DESPITE having a separate > > --with-XXX=path-to-XXX-config option TELLING it exactly where to look) >and > > even then I find myself having to set LD_LIBRARY_PATH, LDFLAGS, CFLAGS >and > > CPPFLAGS variables to help it along - this shouldn't be necessary. > >Maybe it's easier to set GTK_CONFIG to the path to gtk-config? That's >the only thing I ever did to get xscanimage working on some non-linux >platforms. An why don't put the XXX-config file into the path? > > > Perhaps Linux people don't have this trouble - but if all the world is >to run > > Linux, why bother with ./configure ? :-))) > >Even Linux is different :-). E.g. not every library is everywhere. But >SANE is definitely not Linux-only, I test at least compilation with >FreeBSD, NetBSD, OpenBSD, Solaris, Irix and AIX. However, most of >these systems don't have scanners and some don't have gtk and/or gimp >so testing isn't complete. > > > Do you need contributors? > >Absolutely! > > > When I get more time maybe I'll take a look > > at joining in and trying to help fix some of these issues. > >That appreciated very much. > >Bye, > henning >_______________________________________________ >Sane-devel mailing list >[email protected] >http://www.mostang.com/mailman/listinfo/sane-devel _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com
