[sane-devel] MacOS X SCSI support and other changes in SANE CVS
On Thu, May 01, 2003 at 01:33:03AM +0200, Henning Meier-Geinitz wrote: > MacOS X users: Please test now. I haven't got any report about failure > or acces until now. If it's not tested, Mac OS X builds may be broken > in the next release. I don't have a SCSI card in my PowerMac, so I can't test that part, but I did try to simply build it, and got the following error: gcc -o .libs/scanimage scanimage.o stiff.o ../backend/.libs/libsane.dylib -framework CoreFoundation -framework IOKit ../lib/liblib.a -lm ld: multiple definitions of symbol _getopt /usr/lib/libm.dylib(getopt.So) definition of _getopt ../lib/liblib.a(getopt.o) definition of _getopt in section (__TEXT,__text) ld: multiple definitions of symbol _opterr /usr/lib/libm.dylib(getopt.So) definition of _opterr ../lib/liblib.a(getopt.o) definition of _opterr in section (__DATA,__data) ld: multiple definitions of symbol _optind /usr/lib/libm.dylib(getopt.So) definition of _optind ../lib/liblib.a(getopt.o) definition of _optind in section (__DATA,__data) ld: multiple definitions of symbol _optopt /usr/lib/libm.dylib(getopt.So) definition of _optopt ../lib/liblib.a(getopt.o) definition of _optopt in section (__DATA,__data) make[1]: *** [scanimage] Error 1 make: *** [all-recursive] Error 1 This is on a machine running MacOS X 10.2.5 Darwin greyfox.azeotrope.org 6.5 Darwin Kernel Version 6.5: Mon Apr 7 17:05:38 PDT 2003; root:xnu/xnu-344.32.obj~1/RELEASE_PPC Power Macintosh powerpc -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 27 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
[sane-devel] MacOS X SCSI support and other changes in SANE CVS
On Sat, May 03, 2003 at 02:03:29PM +0200, Henning Meier-Geinitz wrote: > Ok. That's changed in the latest snapshot on > http://www.meier-geinitz.de/sane/snapshots/sane-backends-2003-05-03.tar.gz That version compiles fine on my MacOS X machine, and seems to work too :) (tested with scanimage and the net backend; I don't have a scanner physically hooked up to that computer.) -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 27 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
[sane-devel] DLL backend doesn't work on 680x0 machines
I've been using an old (68k) Mac running NetBSD as my scanning machine, and ever since upgrading it to NetBSD 1.6, SANE quit working--it says that it can't find any scanners. I just got around to trying to figure out what was wrong, and it turns out the trigger was that NetBSD on 68k machines switched from a.out to ELF. Along with the change in object formats was a change in the ABI. In particular, how function return values were returned. With a.out, all functions return values in the D0 register, but with ELF, integral types are returned in the D0 register, but pointers are returned in the A0 register. SANE's DLL backend doesn't work under that scheme, because "op" in struct backend is declared as "void *(*op[NUM_OPS]) ()". I.e., a function that returns a pointer. However, in the various backends, the actual functions generally return SANE_Status, a non-pointer. In my case, I have an HP scanner, and sane_hp_init() was returning SANE_STATUS_GOOD in the D0 register. However, when dll.c's init() called it with: status = (long) (*be->op[OP_INIT]) (&version, auth_callback); it was setting status to the value of the A0 register, which contained some leftover pointer, and was not SANE_STATUS_GOOD. There are a couple of solutions... keep "op" in struct backend as a function that returns a pointer, and change all the non-void backend operations to actually return a pointer; change "op" in struct backend to a function that returns an integer (such as intptr_t), and change the non-void backend ops to return integers (which they all do already, except for get_option_descriptor); or change the places where the ops are called and cast the function pointer to match the particular op being called, rather than casting the result of the call. E.g., for the above call to init: status = (*(SANE_Status(*)())be->op[OP_INIT]) (&version, auth_callback); Since the latter option touches the least amount of code, here's a patch: --- backend/dll.c.orig Wed Dec 4 14:30:26 2002 +++ backend/dll.c Fri Apr 11 17:50:23 2003 @@ -481,7 +481,7 @@ DBG (3, "init: initializing backend `%s'\n", be->name); - status = (long) (*be->op[OP_INIT]) (&version, auth_callback); + status = (*(SANE_Status(*)())be->op[OP_INIT]) (&version, auth_callback); if (status != SANE_STATUS_GOOD) return status; @@ -790,7 +790,7 @@ if (init (be) != SANE_STATUS_GOOD) continue; - status = (long) (*be->op[OP_GET_DEVS]) (&be_list, local_only); + status = (*(SANE_Status(*)())be->op[OP_GET_DEVS]) (&be_list, local_only); if (status != SANE_STATUS_GOOD || !be_list) continue; @@ -929,7 +929,7 @@ return status; } - status = (long) (*be->op[OP_OPEN]) (dev_name, &handle); + status = (*(SANE_Status(*)())be->op[OP_OPEN]) (dev_name, &handle); if (status != SANE_STATUS_GOOD) return status; @@ -973,7 +973,7 @@ DBG (3, "sane_control_option(handle=%p,option=%d,action=%d,value=%p,info=%p)\n", handle, option, action, value, info); - return (long) (*s->be->op[OP_CTL_OPTION]) (s->handle, option, action, value, + return (*(SANE_Status(*)())s->be->op[OP_CTL_OPTION]) (s->handle, option, action, value, info); } @@ -983,7 +983,7 @@ struct meta_scanner *s = handle; DBG (3, "sane_get_parameters(handle=%p,params=%p)\n", handle, params); - return (long) (*s->be->op[OP_GET_PARAMS]) (s->handle, params); + return (*(SANE_Status(*)())s->be->op[OP_GET_PARAMS]) (s->handle, params); } SANE_Status @@ -992,7 +992,7 @@ struct meta_scanner *s = handle; DBG (3, "sane_start(handle=%p)\n", handle); - return (long) (*s->be->op[OP_START]) (s->handle); + return (*(SANE_Status(*)())s->be->op[OP_START]) (s->handle); } SANE_Status @@ -1003,7 +1003,7 @@ DBG (3, "sane_read(handle=%p,data=%p,maxlen=%d,lenp=%p)\n", handle, data, max_length, length); - return (long) (*s->be->op[OP_READ]) (s->handle, data, max_length, length); + return (*(SANE_Status(*)())s->be->op[OP_READ]) (s->handle, data, max_length, length); } void @@ -1022,7 +1022,7 @@ DBG (3, "sane_set_io_mode(handle=%p,nonblocking=%d)\n", handle, non_blocking); - return (long) (*s->be->op[OP_SET_IO_MODE]) (s->handle, non_blocking); + return (*(SANE_Status(*)())s->be->op[OP_SET_IO_MODE]) (s->handle, non_blocking); } SANE_Status @@ -1031,5 +1031,5 @@ struct meta_scanner *s = handle; DBG (3, "sane_get_select_fd(handle=%p,fdp=%p)\n", handle, fd); - return (long) (*s->be->op[OP_GET_SELECT_FD]) (s->handle, fd); + return (*(SANE_Status(*)())s->be->op[OP_GET_SELECT_FD]) (s->handle, fd); } -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 27 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
[sane-devel] DLL backend doesn't work on 680x0 machines
On Sat, Apr 12, 2003 at 12:42:11PM +0200, Henning Meier-Geinitz wrote: > Is this 68k-specific? I'm surprised that nobody else has reported this > problem. I think any platform that has a different method of returning pointers and integers would have the problem... I don't know of any besides 68k though. Of the CPUs I know of, only 68k makes a distinction between registers that contain pointers (A0-A7, the address registers) and ones that contain integers (D0-D7, the data registers). > Oh, a.out. That was before I started using Unix. I didn't know that > NetBSD used it. What about the other BSDs? NetBSD switched from a.out to ELF, and the problem showed up after the switch. I suspect the various 68k ports of Linux would have the problem too. Of the other BSDs, only OpenBSD runs on the 68k. I don't know whether they use a.out or ELF though--probably still a.out. > It works (at least on Linux/i386). But I'm getting a warning for all > the lines you changed: > > dll.c: In function init': > dll.c:484: warning: function declaration isn't a prototype > > Is the warning ok or should I just ignore it? Any way to shut gcc up? Hmm, I didn't get any warning with gcc 2.95.3 on either m68k or alpha. Which version of gcc are you using? I never was very good with declaring pointers to functions; it's possible that I have some misplaced parentheses or something. I'll try it on another machine that has gcc 3.1 and see if I can figure out what's wrong. Thanks :)
[sane-devel] DLL backend doesn't work on 680x0 machines
n", handle, option); - return (*s->be->op[OP_GET_OPTION_DESC]) (s->handle, option); + return (*(op_get_option_desc_t)s->be->op[OP_GET_OPTION_DESC]) (s->handle, option); } SANE_Status @@ -973,7 +990,7 @@ DBG (3, "sane_control_option(handle=%p,option=%d,action=%d,value=%p,info=%p)\n", handle, option, action, value, info); - return (long) (*s->be->op[OP_CTL_OPTION]) (s->handle, option, action, value, + return (*(op_ctl_option_t)s->be->op[OP_CTL_OPTION]) (s->handle, option, action, value, info); } @@ -983,7 +1000,7 @@ struct meta_scanner *s = handle; DBG (3, "sane_get_parameters(handle=%p,params=%p)\n", handle, params); - return (long) (*s->be->op[OP_GET_PARAMS]) (s->handle, params); + return (*(op_get_params_t)s->be->op[OP_GET_PARAMS]) (s->handle, params); } SANE_Status @@ -992,7 +1009,7 @@ struct meta_scanner *s = handle; DBG (3, "sane_start(handle=%p)\n", handle); - return (long) (*s->be->op[OP_START]) (s->handle); + return (*(op_start_t)s->be->op[OP_START]) (s->handle); } SANE_Status @@ -1003,7 +1020,7 @@ DBG (3, "sane_read(handle=%p,data=%p,maxlen=%d,lenp=%p)\n", handle, data, max_length, length); - return (long) (*s->be->op[OP_READ]) (s->handle, data, max_length, length); + return (*(op_read_t)s->be->op[OP_READ]) (s->handle, data, max_length, length); } void @@ -1012,7 +1029,7 @@ struct meta_scanner *s = handle; DBG (3, "sane_cancel(handle=%p)\n", handle); - (*s->be->op[OP_CANCEL]) (s->handle); + (*(op_cancel_t)s->be->op[OP_CANCEL]) (s->handle); } SANE_Status @@ -1022,7 +1039,7 @@ DBG (3, "sane_set_io_mode(handle=%p,nonblocking=%d)\n", handle, non_blocking); - return (long) (*s->be->op[OP_SET_IO_MODE]) (s->handle, non_blocking); + return (*(op_set_io_mode_t)s->be->op[OP_SET_IO_MODE]) (s->handle, non_blocking); } SANE_Status @@ -1031,5 +1048,5 @@ struct meta_scanner *s = handle; DBG (3, "sane_get_select_fd(handle=%p,fdp=%p)\n", handle, fd); - return (long) (*s->be->op[OP_GET_SELECT_FD]) (s->handle, fd); + return (*(op_get_select_fd_t)s->be->op[OP_GET_SELECT_FD]) (s->handle, fd); } -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 27 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
[sane-devel] DLL backend doesn't work on 680x0 machines
On Sat, Apr 12, 2003 at 08:09:22PM -0500, Dave Huang wrote: > used the net backend. That all worked fine, but scanimage -h from a > remote machine causes saned on the m68k machine to crash trying to > write to a null pointer when scanimage gets the list of options... > here's the end of the log from saned with SANE_DEBUG_DLL set to 4: > > [dll] > sane_control_option(handle=0x101e0,option=15,action=0,value=0x10180,info=0xc8dc) > [dll] > sane_control_option(handle=0x101e0,option=18,action=0,value=0x10180,info=0xc8dc) > [dll] > sane_control_option(handle=0x101e0,option=19,action=0,value=0x0,info=0xc8dc) > > note that value is 0x0... it's correct for all the previous calls to > sane_control_option, so I don't know why it's different for option=19. > Also, I don't know if this is caused by my patch, or if this is a > completely unrelated problem. I think this is unrelated, since the function parameters are being passed correctly from the dll backend to the real hardware driver backend (hp, in my case). The problem is that the dll backend is being called with a null pointer. Perhaps someone who understands the net backend and/or the wire protocol stuff will know what's going on... w_option_value() is being called, with type = SANE_TYPE_BUTTON, so w_value = (WireCodecFunc) sanei_w_void; len = 0; element_size = 0; Then in sanei_w_array(), if len == 0, the value is set to 0. That 0 is passed along until it eventually gets to hp_accessor_bool_get as the valp pointer, which then does: *(SANE_Bool*)valp = val ? SANE_TRUE : SANE_FALSE; Dereference of NULL valp causes a segmentation fault. Here's a stack trace... and no, I don't know why gdb thinks some of these functions are in /usr/include/stdio.h :) #0 0x810f86a in hp_accessor_bool_get (this=0xed68, data=0x20148, valp=0x0) at hp-accessor.c:901 #1 0x810f548 in sanei_hp_accessor_get (this=0xed68, data=0x20148, valp=0x0) at hp-accessor.c:901 #2 0x8113812 in hp_option_get (this=0xed08, data=0x20148, valp=0x0) at /usr/include/stdio.h:428 #3 0x8113f2e in hp_option_imm_control (optset=0x1e008, this=0xed08, data=0x20148, action=SANE_ACTION_GET_VALUE, valp=0x0, infop=0xc8b4, scsi=0x16008) at /usr/include/stdio.h:428 #4 0x8119798 in sanei_hp_optset_control (this=0x1e008, data=0x20148, optnum=19, action=SANE_ACTION_GET_VALUE, valp=0x0, infop=0xc8b4, scsi=0x16008, immediate=1) at /usr/include/stdio.h:428 #5 0x811214a in sanei_hp_handle_control (this=0x14788, optnum=19, action=SANE_ACTION_GET_VALUE, valp=0x0, info=0xc8b4) at hp-handle.c:697 #6 0x810cca4 in sane_hp_control_option (handle=0x14788, optnum=19, action=SANE_ACTION_GET_VALUE, valp=0x0, info=0xc8b4) at hp.c:972 #7 0x80256fc in sane_dll_control_option (handle=0x111e0, option=19, action=SANE_ACTION_GET_VALUE, value=0x0, info=0xc8b4) at dll.c:1052 #8 0x8025a08 in sane_control_option (h=0x111e0, opt=19, act=SANE_ACTION_GET_VALUE, val=0x0, info=0xc8b4) at dll-s.c:83 #9 0x5c5a in process_request (w=0xdbe0) at saned.c:1040 #10 0x64f4 in main (argc=2, argv=0xc998) at saned.c:1310 #11 0x3b88 in __start ()
[sane-devel] DLL backend doesn't work on 680x0 machines
On Sat, Apr 12, 2003 at 02:58:19PM +0200, Julien BLACHE wrote: > We still have this old (2 years and 146 days) Debian bug report : > <http://bugs.debian.org/77356> > > If there is some kind of fix available, I could get someone to test it > on Linux/m68k. The problem reported in that bug report looks exactly like the one I was seeing <http://mail-index.netbsd.org/port-mac68k/2002/09/26/0002.html> I'm pretty sure the patch I posted will fix it; it'd certainly be interesting to have someone test it on a non-NetBSD m68k platform. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 27 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
[sane-devel] hp backend bug? (was: DLL backend doesn't work on 680x0 machines)
On Sun, Apr 13, 2003 at 09:04:18PM +0200, Peter Kirchgessner wrote: > Hi, > > I will pick it up and look for it. Let me know if you need any more information about the problem or my configuration... scanimage -L says: device `hp:/dev/uk0' is a Hewlett-Packard C2500A flatbed scanner And when running scanimage -h remotely, saned crashes between --source and --lamp-off: [ many options here ] --output-8bit[=(yes|no)] [inactive] Use bit depth greater eight internally, but output only eight bits --source Normal|XPA [Normal] Selects the scan source (such as a document-feeder). [ saned crashes here ] --lamp-off [] Shut off scanner lamp. Geometry: -l 0..215.788mm (in steps of 1.52588e-05) [0] Top-left x position of scan area. [ a few more options here ] Thanks!
[sane-devel] DLL backend doesn't work on 680x0 machines
On Sun, Apr 13, 2003 at 03:25:53PM +0200, Henning Meier-Geinitz wrote: > Could you please try on your 68k system if compiling with ./configure > --disable-shared also works? I'll attach the complete dll backend > because there have been some other (minor) changes. Yes, it works. Thanks!
