Re: [cups] Still conceptually possible to use SCSI backend in latest CUPS?
Protea Wines Japan <[email protected]>
| Newsgroups | gmane.comp.printing.cups.general |
|---|---|
| Message-ID | <CAN0dEZxP=e-Sz6b2Wd_5o2Mc-4gvXTpBsScSpr_CZ8m2-s=ttg@mail.gmail.com> |
On Mon, Feb 22, 2021 at 3:59 PM Jörg Thümmler <[email protected]> wrote: Hallo Jörg, Many thanks for the reply. > Am 20.02.21 um 18:47 schrieb Protea Wines Japan: > > On Fri, Feb 19, 2021 at 4:01 PM Johannes Meixner <[email protected]> wrote: > >> > >> On 2021-02-18 18:20, Protea Wines Japan wrote (excerpt): > >>> Is it conceptually still possible to compile > >>> the old scsi.c backend in CUPS 1.2 > >> > >> conceptually a CUPS backend is an arbitrary program > >> that gets data and sends it to a recipient, see > >> > >> https://en.opensuse.org/SDB:Using_Your_Own_Backends_to_Print_with_CUPS > > > > Many thanks Johannes, I could tell from your document that there is nothing > > specifically preventing the SCSI backend from being used, provided it uses > > the right commands to the SCSI high-level driver. > > I spent some time reading up on the SCSI subsystem in linux again, and the > > sg3 high-level driver. > > It looks like the scsi.c file should still be compilable and usable as is, > > since it uses the sg_io_hdr which is what is currently used in sg3 also. > > > > I ran into a problem with compiling though. I wonder if you or anyone > > familiar with the current (forked?) CUPS code can help: > > > > hase@hase:~/src/CUPS-SCSI-Backend$ gcc -o scsi-backend scsi.c > > In file included from scsi.c:59: > > /usr/include/cups/i18n.h:18:12: fatal error: config.h: No such file or > > directory > > 18 | # include "config.h" > > | ^~~~~~~~~~ > > compilation terminated. > > > > It looks like the CUPS header file config.h is missing. I am not sure where > > I should find this, I have all available development packages installed I > > think. Even downloading the Debian CUPS source package does not find this > > file although there are 2 config.h files in subsystem source trees: > > hase@hase:~/src/CUPS-SCSI-Backend/cups-2.3.3op2$ find . -name config.h > > ./vcnet/config.h > > ./xcode/config.h > > > > As for linux, there are 2 config.h files in the source tree (none in the > > common headers): > > hase@hase:~/src/CUPS-SCSI-Backend/cups-2.3.3op2$ find > > /usr/src/linux-headers-5.10.0-3-amd64 -name config.h > > /usr/src/linux-headers-5.10.0-3-amd64/include/config/snd/intel/dsp/config.h > > /usr/src/linux-headers-5.10.0-3-amd64/include/config/pci/lockless/config.h > Hi, > > i'm in no case familiar with cups code ;-) > > But your "gcc -o scsi-backend scsi.c" may need some -I<dir> option (see > man gcc) as it may not find the config.h in its standard include path. > > Or - another "blind shot" - you may have to install the kernel header > files therefor. "i18n.h" sounds like an include a lot of programs will > use so it may be will look for a "central" config.h... > > At least a look into this i18n.h will maybe show, in which context the > "config.h" is searched and that may give you a hint, which "config.h" to > include. > > Another way may be to use the "configure" feature (if cups-devel has > that), which usually does the trick of writing of correct make files for > compiling and then try to find a appropriate gcc line for some analogue > backend compiling. Will do. I already discovered in the meantime trying something like you suggest but just with examination of the current Debian CUPS package source code, that cups has many files like i18n-private.h which are copied to i18n.h by the configuration script. I see many other header files that should be produced by configure, but they do not match well the existing CUPS header files in my /usr/include/cups directory, which are supplied by libcups2-dev. I therefore came to the conclusion, perhaps too soon, that maybe the CUPS development packages are not in sync with the current CUPS package. I checked that I already have the linux-headers package installed. I also tried to grab header files from existing backends in the Debian CUPS source package, as well as updating the logic for SIGSET and SIGACTION, still errors though. Now I will check what happens if I compile the CUPS source package in /opt or something like that, whether come include files are generated that I can make use of instead of the current ones provided by libcups2-dev. Best regards, Gernot Hassenpflug _______________________________________________ cups mailing list [email protected] https://lists.cups.org/mailman/listinfo/cups