[cups] Still conceptually possible to use SCSI backend in latest CUPS?
Protea Wines Japan
aikishugyo at gmail.com
Mon Feb 22 12:21:53 PST 2021
On Tue, Feb 23, 2021 at 5:11 AM Protea Wines Japan <aikishugyo at gmail.com>
wrote:
> On Mon, Feb 22, 2021 at 4:54 PM Protea Wines Japan <aikishugyo at gmail.com>
> wrote:
>
>> On Mon, Feb 22, 2021 at 3:59 PM Jörg Thümmler
>> <listen at vordruckleitverlag.de> wrote:
>>
>>
> I am happy to report I could compile scsi.c after some modifications, see
> below.
> Thank you for all the help on this, much appreciated.
>
Just to add, I had tried this in April 2016, here is a link to my previous
attempt, which I had forgotten about:
https://lists.cups.org/pipermail/cups/2016-April/027672.html
Still got to test the actual operation, but I wonder if cups-filters would
be interested in taking on the SCSI backend into their fold?
Best regards,
Gernot Hassenpflug
> /../
>> > Am 20.02.21 um 18:47 schrieb Protea Wines Japan:
>> > > On Fri, Feb 19, 2021 at 4:01 PM Johannes Meixner <jsmeix at suse.de>
>> 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'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.
>>
>
> After another night of getting header files sorted out, but undefined
> reference errors on compile, and then some online searching to kick my
> rusty memory, it looks like that was the case.
> The header files supply merely the declaration, but not the definition.
>
> I could finally do the compilation as follows:
> 1. comment out the config.h line in /usr/include/cups/i18n.h
> 2. include as many header files as needed to cover all the declarations
> (now I have way too many I expect)
> 3. update a couple of functions that have changed since the original
> scsi.c was removed in CUPS 1.4
> 4. link libcups.so in the compilation (definition required is in
> langprintf.c which goes into libcups)
>
> Then the compile command becomes:
> gcc -o scsi scsi.c -lcups
>
> > 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.
>>
>
> That is a good idea, fortunately I could find a workable solution without
> executing configure, although I did look at the configure script and took
> some header files from it into the backend just to be sure I am not missing
> some.
>
> Below is the difference between the newly-compiled scsi.c and the original
> scsi.c which I found at
> https://opensource.apple.com/source/cups/cups-97.4/cups/
>
> The scsi-linux.c dependency program was used as is.
>
> ==== START ====
> $ diff -uw scsi.c-original scsi.c
> --- scsi.c-original 2021-02-22 03:47:01.175005309 +0900
> +++ scsi.c 2021-02-23 04:54:11.668911500 +0900
> @@ -54,16 +54,27 @@
> * Include necessary headers.
> */
>
> +/* taken from other newer backends */
> +#include <cups/http.h>
> #include <cups/backend.h>
> +#include <stdarg.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <stdio.h>
> +
> +/* added back from original */
> +#include <signal.h>
> #include <cups/cups.h>
> #include <cups/i18n.h>
> -#include <stdio.h>
> #include <stdlib.h>
> #include <errno.h>
> -/* #include <cups/string.h> */
> +
> +/* included from CUPS configure script */
> #include <string.h>
> -#include <cups/i18n.h>
> -#include <signal.h>
> +#include <strings.h>
> +#include <inttypes.h>
> +#include <stdint.h>
> +#include <unistd.h>
>
> #ifdef WIN32
> # include <io.h>
> @@ -109,7 +120,9 @@
> main(int argc, /* I - Number of command-line arguments (6 or 7) */
> char *argv[]) /* I - Command-line arguments */
> {
> - char method[255], /* Method in URI */
> + const char *device_uri; /* Device URI */
> + char scheme[255], /* Scheme in URI */
> + /* method[255], */ /* [OLD] Method in URI */
> hostname[1024], /* Hostname */
> username[255], /* Username info (not used) */
> resource[1024], /* Resource info (device and options) */
> @@ -143,6 +156,7 @@
> signal(SIGPIPE, SIG_IGN);
> #endif /* HAVE_SIGSET */
>
> +
> /*
> * Check command-line...
> */
> @@ -189,9 +203,8 @@
> * Extract the device name and options from the URI...
> */
>
> - httpSeparateURI(HTTP_URI_CODING_ALL, cupsBackendDeviceURI(argv),
> - method, sizeof(method), username, sizeof(username),
> - hostname, sizeof(hostname), &port,
> + httpSeparateURI(HTTP_URI_CODING_ALL, device_uri, scheme, sizeof(scheme),
> + username, sizeof(username), hostname, sizeof(hostname),
> &port,
> resource, sizeof(resource));
>
> /*
> ==== END ====
>
> Next is to test whether this works or not.
> Copied to: /usr/lib/cups/backend/scsi
> Will try to test with an ALPS MD-2000S attached to my Adaptec AHA-2910
> card.
> --
> Gernot Hassenpflug
>
--
Protea Wines Japan
Tel: 070-5550-9076
https://www.proteawines.jp
More information about the cups
mailing list