[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