Hi,
On Sun, Dec 29, 2002 at 01:54:41AM +0100, Andrea Suatoni wrote:
> I have packaged the SANE 1.0.9 backends / frontends for IRIX, using the SGI
> MIPSpro C compiler. The packages should upgrade the 1.0.8 versions currently
> available on http://freeware.sgi.com/
Thanks.
> In order to compile properly the two packages,
Was there anything that didn't compile at all? I don't ahve access to
Irix any longer, so the last version tested was 1.0.8.
I have some questions about some of these patches:
> +++ sane-backends-1.0.9-patched/backend/Makefile.in Thu Dec 12 21:55:32 2002
> @@ -46,6 +46,7 @@
> CFLAGS = @CFLAGS@
> LDFLAGS = @LDFLAGS@
> BACKENDLIBS = @LIBS@ @DL_LIB@
> +GPHOTO2_LIBS = @GPHOTO2_LIBS@
> DEFS = @DEFS@
>
> LIBTOOL = ../libtool
> @@ -135,6 +136,11 @@
>
>
> .PHONY: all clean depend dist distclean install uninstall
> +
> +libsane-gphoto2.la: gphoto2.lo gphoto2-s.lo $(EXTRA) $(LIBOBJS)
> + @$(LIBTOOL) $(MLINK) $(CC) -export-dynamic -o $@ $($*_LIBS) \
> + $(LDFLAGS) $(GPHOTO2_LIBS) $(BACKENDLIBS) $^ -rpath $(libsanedir) \
> + -version-info $(V_MAJOR):$(V_REV):$(V_MINOR)
>
> libsane-%.la: %.lo %-s.lo $(EXTRA) $(LIBOBJS)
> @$(LIBTOOL) $(MLINK) $(CC) -export-dynamic -o $@ $($*_LIBS) \
What's the reason for the gphoto2 changes and the separate rule for
building the library?
> diff -ruN sane-backends-1.0.9/backend/as6e.c
> sane-backends-1.0.9-patched/backend/as6e.c
> --- sane-backends-1.0.9/backend/as6e.c Tue Dec 5 20:10:20 2000
> +++ sane-backends-1.0.9-patched/backend/as6e.c Thu Dec 12 21:56:54 2002
> @@ -604,8 +604,7 @@
> return (SANE_STATUS_GOOD);
> } /*else */
> }
> - else
> - return (SANE_STATUS_IO_ERROR);
> + return (SANE_STATUS_IO_ERROR);
> }
Is this to fix a warning or is this a real change in code?
> +++ sane-backends-1.0.9-patched/backend/canon-sane.c Thu Dec 12 21:58:46 2002
> @@ -1798,7 +1798,7 @@
> SANE_Status status;
> SANE_Byte *out, *red, *green, *blue;
> SANE_Int ncopy;
> - size_t nread, i, pixel_per_line;
> + size_t nread = 0, i, pixel_per_line;
>
> DBG (21, ">> read_fb620\n");
>
That's because of the DBG that prints nread before initializing it?
The correct fix is to move the DBG after the setting nread, I guess.
> +++ sane-backends-1.0.9-patched/include/sane/config.h.in Thu Dec 12
> 23:36:53 2002
> @@ -393,3 +393,13 @@
>
> /* Define to `unsigned long' if <sys/types.h> does not define. */
> #undef u_long
> +
> +/* Define a the function prototypes if these function are missing. */
> +#ifndef HAVE_STRSEP
> +char *strsep(char **stringp, const char *delim);
> +#endif
> +
> +#ifndef HAVE_STRNDUP
> +#include <sys/types.h>
> +char *strndup(const char * s, size_t n);
> +#endif
This will be removed automatically with the next run of autoheader. If
it makes sense to add these declarations, I can put the code for
generation in configure.in.
> +++ sane-frontends-1.0.9-patched/src/Makefile.in Fri Dec 13 00:39:37 2002
> @@ -83,7 +83,7 @@
> $(DESTDIR)$(bindir)/$${program}; \
> done
> $(INSTALL_DATA) $(srcdir)/sane-style.rc \
> - $(DESTDIR)$(datadir)/sane-style.rc
> + $(DESTDIR)$(sanedatadir)/sane-style.rc
>
> uninstall:
> @for program in $(BINPROGS); do \
> @@ -90,7 +90,7 @@
> echo removing $(bindir)/$${program}...; \
> rm -f $(bindir)/$${program}; \
> done
> - rm -f $(datadir)/sane-style.rc
> + rm -f $(sanedatadir)/sane-style.rc
>
> xscanimage: $(XSCANIMAGE_OBJS) $(LIBSANEI) $(LIBLIB)
> $(LINK) $(XSCANIMAGE_OBJS) $(LIBSANEI) \
That one is cool. Nobody has ever found out about this one. Will be
applied to CVS.
> diff -ruN sane-frontends-1.0.9/src/xcam.c
> sane-frontends-1.0.9-patched/src/xcam.c
> --- sane-frontends-1.0.9/src/xcam.c Sat Jun 9 14:52:05 2001
> +++ sane-frontends-1.0.9-patched/src/xcam.c Fri Dec 13 00:41:42 2002
> @@ -56,8 +56,6 @@
> }
> Canvas;
>
> -Preferences preferences;
> -
> static const char *prog_name;
> static const SANE_Device **device;
> static GSGDialog *dialog;
> @@ -672,13 +670,29 @@
> \
> case 24: \
> /* Is this correctly handling all byte order cases? */ \
> - if ((endian) == GDK_LSB_FIRST) \
> + if ((endian) != GDK_LSB_FIRST) \
> { \
> - buf[0] = (b) >> 8; buf[1] = (g) >> 8; buf[2] = (r) >> 8; \
> + if (bpp == 4) \
> + { \
> + buf[1] = (b) >> 8; buf[2] = (g) >> 8; buf[3] = (r) >> 8; \
> + buf[0] = 0; \
> + } \
> + else \
> + { \
> + buf[0] = (b) >> 8; buf[1] = (g) >> 8; buf[2] = (r) >> 8; \
> + } \
> } \
> else \
> { \
> - buf[0] = (r) >> 8; buf[1] = (g) >> 8; buf[2] = (b) >> 8; \
> + if (bpp == 4) \
> + { \
> + buf[1] = (r) >> 8; buf[2] = (g) >> 8; buf[3] = (b) >> 8; \
> + buf[0] = 0; \
> + } \
> + else \
> + { \
> + buf[0] = (r) >> 8; buf[1] = (g) >> 8; buf[2] = (b) >> 8; \
> + } \
> } \
> buf += (bpp); \
> break; \
> @@ -687,7 +701,7 @@
> /* Is this correctly handling all byte order cases? It assumes
> \
> the byte order of the host is the same as that of the \
> pixmap. */ \
> - rgb = (((r) >> 8) << 16) | (((g) >> 8) << 8) | ((b) >> 8); \
> + rgb = (((b) >> 8) << 16) | (((g) >> 8) << 8) | ((r) >> 8); \
> ((guint32 *)buf)[0] = rgb; \
> buf += (bpp); \
> break; \
That one doesn't work on Linux/X11/i386. The colors are wrong. The old
code was correct (at least for 24 bit, 4 bytes per pixel, little
endian). Well, at least it worked here :-)
I'm fascinated that someone actually cares about xcam :-)
Bye,
Henning
