[sane-devel] Found: why Sane make barfed under RH6.1

[Gene Heskett]

On Tuesday 12 March 2002 08:32 pm, Douglas Gilbert wrote:
>john meshkoff wrote:
>> The error:
>>
>> sanei_scsi.c: In function `sanei_scsi_req_wait':
>> sanei_scsi.c:2079: structure has no member named `host_status'
>> sanei_scsi.c:2080: structure has no member named `host_status'
>> sanei_scsi.c:2081: structure has no member named `host_status'
>> sanei_scsi.c:2082: structure has no member named
>> `driver_status' sanei_scsi.c:2083: structure has no member
>> named `target_status'
>>
>> The versions of /scsi/sg.h available at the time:
>>
>> ivan:~$ locate /include/scsi/sg.h
>> /usr/include/scsi/sg.h
>> /usr/include/scsi/sg.h.bak	/* the originally installed version
>> */ /usr/local/src/include/scsi/sg.h
>> /usr/src/linux-2.2.12/include/scsi/sg.h	/* originally
>> installed kernel sources */
>> /usr/src/redhat/SOURCES/linux-2.2.19/include/scsi/sg.h
>> /usr/src/redhat/SOURCES/linux-2.2.16/include/scsi/sg.h
>> /usr/src/redhat/SOURCES/dosemu-1.0.1/src/include/scsi/sg.h
>> /usr/i386-glibc20-linux/include/scsi/sg.h
>>
>>
>>
>> Interesting result of detective work on my RH6.1 install; the
>> only version of sg.h that was incompatible with the Sane make
>> was the one I show
>> re-named as sg.h.bak, which was installed by RH6.1, along with
>> the 2.2.12-20
>> kernel, yet the version included under the 2.2.12-20 kernel
>> sources is compatible, so
>> are all the others in all the above listed include
>> directories.  So it looks
>> like the make barfing on "structure has no member named" is
>> due to the wrong
>> version of the sg.h file having been installed by RH6.1 in
>> /usr/include, despite
>> the correct version having been included by that install under
>> the 2.2.12 kernel sources tree.
>>
>> 	The question was raised to me as to whether my kernel was
>> compiled against  the updated sg.h file so as to prevent
>> possible weird behavior by Sane; so I'm wondering, would a
>> kernel compiled from sources, be compiled against the includes
>> under it's own source tree, or those under /usr/include?  If
>> the former, then all the kernels above were compiled against
>> compatible versions, but any program makeing against
>> /user/include/scsi would have encountered an incompatible
>> version, prior to my updating of it.
>
>John,
>The kernel compiles the sg driver (either built-in or a module)
>against the /<kernel_source_root>/include/scsi/sg.h header.
>It would be difficult (but not impossible) to get that file
>"out of sync" with the /<kernel_source_root>/drivers/scsi/sg.c
>file. I am the maintainer of those 2 files.
>
>SANE builds against /usr/include/scsi/sg.h which is maintained
>by the glibc people. Linux kernel source and glibc are
> distributed (almost) independently. Files such as sg.h are why
> "almost" is needed in the previous sentence :-) There is not
> much I can do about this contention other than point it out to
> people.
>
>Doug Gilbert

Is there some 'carved in stone' rule that says he can't take the 
sg.h from his kernel tree and put it in the usr/includes tree?

ISTR I ran into a similar problem while trying to build something 
(taper-6.9b maybe?) quite a ways back to the log, as in year+, 
and wound up putting the kernel includes I needed right on top of 
the ones that were being a problem child.  IIRC it worked ok for 
that compile, and I can't for the life of me recall whether I 
ever undid that fix or not.  I don't think I did, and between 
then and the install of RH7.2 I built quite a few other things 
from scratch.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
98.6+% setiathome rank, not too shabby for a hillbilly