[sane-devel] sane-backends master e13b80fa -- odd looking sprintf format strings

[Olaf Meeuwissen]

Hi Robert,

Robert A. Schmied writes:

> aloha Olaf
>
> i started to fire you off a short note, but it grew and grew
>
> sorry, but i tend to get carried away.

Don't worry, I have the same "problem" ;-)

> Olaf Meeuwissen wrote:
>> Robert A. Schmied writes:
>
> [...]
>>
>>>as i'm still
>>>patching in my source hacks to get a clean compile and link on solaris 10
>>>sparc with the sun version of usb.h/libusb (no libusb*.pc file but with
>>>/usr/sfw/bin/libusb-config --version that reports 0.1.7) and old gcc 4.9.
>>
>> # Merge request is welcome :-)
>
> i'm not sure what a merge request is/means.  plus if it is really worth
> while given all one or maybe 3 of us dinosaurs that still use sparc
> hardware and sunos.

Perhaps it's time to put the Cretaceous behind you and fast-forward to
the Cenozoic, preferably all the way up to the Pleistocene?  :-P

> in any event with minimal code tweakage, heavy (but typical) configure
> argument setup this sane-backends version compiled/linked just fine.

Good.

> looks like libpng linking is hosed -- my driving configure args issue.
> looks like something is broken with jpeg -- only half width and half
> length of scan is imaged and background is gray shaded colored snow.

Both PNG and JPEG support are optional.  In the worst case, you can
build without.

> the pnm scan looks fine.
>
> this testing limited to mode color, res 200 and depth 16.
>
> so now i'm looking over the genesys changes between my old hack of
> 1.0.27 originally downloaded 27apr18 and e13b80fa -- there seem to
> be alot.  and i will verify that old hack for jpeg and png work
> as expected.

Yup.  We've got a new genesys maintainer about six months ago and he is
quite active.

> most annoying issue is why umax_pp_low is compiled when it is
> excluded from BACKENDS="genesys net gphoto2 test" to compile and
> PRELOADABLE_BACKENDS="genesys gphoto2".  because umax_pp.c fails
> to compile.  in order to get make (gnu make) to complete and link
> the frontends (scanimage and saned) i'm forced to use -k.

Can you [submit an issue][1] for that?

  [1]: https://gitlab.com/sane-project/backends/issues/new

> it looks like configure is doing the right thing(s) with respect to
> BACKENDS and PRELOADABLE_BACKENDS, so the problem is probably with
> my platform and libtool and or ltmain.sh.  note that the solaris
> /bin/sh is simply not consistent with the typical /bin/sh.

I think your getting those umax_pp_low compile errors when building
stuff in the tools/ directory.  Is that correct?

> any way these three files i change primarily for my os and the sunos
> libusb 0.1.7:
> sanei/sanei_usb.c
> sanei/sanei_auth.c
> sanei/sanei_scsi.c
>
> i've attached the rcsdiff -uBitwb -r1.1 output for each (yep i'm a
> dinosaur that still uses rcs).

We're three VCS "revolutions" past RCS ;-)
That said, RCS is what I started out on.  I moved to CVS shortly after
followed by Subversion, fiddled with Bazaar and TLA before "converting"
to git.  Suggested reading: https://git-scm.com/book

I can manage your rcsdiffs so I'll take a look at what we might want to
merge to the SANE Project's backends.

>   for sanei/sanei_scsi.c
>     i get an error as CDB_SIZE is already defined. the change
>     undefs it if defined then relies on the source file define.

That seems the most sensible approach as we've probably been relying on
that for ages.

>   for sanei/sanei_auth.c and sanei/sanei_usb.c
>     i don't recall if these changes eliminate an error or
>     just fix a warning (thinking the latter as i set -Wall)

Our [CI pipelines][2] use -Wall everywhere and turn warning into errors
on the Debian builds.  Our Debian builds succeed so it's likely a SunOS
issue.

 [2]: https://gitlab.com/sane-project/backends/pipelines

> [...]
> as far as the repository -- is not git exactly as it was a static tarball
> fetched monday 13 around 20:00 gmt from sane-backends-master.  the git
> reference was e13b80fa.

Our source tarballs are *almost* *exactly* the same as what's in the git
repository.  There is only one minor tweak to configure.ac to modify the
version so it includes the git hash (and a `-dirty` moniker to make it
"obvious" that its different from what's in the git repository).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join