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
