olaf interested saners
continuing:
The autotools are a bit of a steep learning curve :unamused:
amen!
first: the submitted configure.ac patch fixes the solaris
usb lib build arguments and the variable settings in
./include/sane/config.h correctly.
it does add ax_path_generic.m4 and ax_compare_version.m4.
ax_path_generic.m4 is where the envvar LIBUSB_* are introduced
iirc, but the envvar name might not be fixed and could
be tweaked to match the sane-backends names USB_*.
[ do not right now recall why ax_compare_version.m4
was needed; maybe needed by ax_path_generic.m4 ? ]
if these two additions are an objection i can see if there
is a way to do it with the autoconf stuff in accordance with
autoconf-2.69: 5.2.2 Generic Program and File Checks.
in fact, at first glance, AC_PATH_PROG does look to be
the solution. naturally AC_PATH_PROG is not in calcotes'
autotools book index! shoulda waited for the 2nd edition
due in sep 2019, but it will be out-of-date by then anyway.
let me dig deeper on this and get back to you with a
different configure.ac patch.
[it will take a while, but it is 'on-the-list']
aloha
ras
the following is 'out-of-band' commentary
second: yep! my "odd-ball os" does indeed provide
a nearly 15 year old usb lib, then again the
entire "odd-ball os" is nearly that old too:
solaris 10 update 8 is dated oct 2009.
twok:(inet)-root 1313 $ libusb-config --version
0.1.7
yep! it is "old". should i see if i could upgrade,
maybe; but recall that this is an "odd-ball os"
(e.g. bigendian, sparc, with a custom svr4-ish
kernel crafted by a company no longer in existence).
certainly not a platform (actively) supported by
the usblib build system. further consider that
the usb stuff might be so inter-woven into the fabric
of the sun solaris kernel that the effort has
a high likelihood of failure.
now consider: is there any actual reason to upgrade?
the 0.1.7 libusb has all the functions needed for
sane-backends-1.0.27 (sane-backends-1.0.x with c++
'improvements' might be a different story), but
right now there isn't much that says an upgrade
is necessary, required or even worth while.
second part 2: why not upgrade to a newer or newest
solaris 10/11 for sparc. well, i've looked over
the licensing associated licensing agreement(s)
and it looks to me that too do so would either
require buying annual renewal or some-such or
risk it and run illegally. the first is out-of-budget,
the second is, well, illegal. oracle seems
not to want to provide an allowance for non-commercial,
personal use like sun micro did. [sol10u8 is the
last solaris release under the sun micro banner]
third: linux -- i'd like to upgrade, but i don't
have a lot of available $$$ to replace my old
legacy hardware. then what hardware and which
of the dozens of linux do i select and why those
particular selections over the other dozens of
choices. then consider the effort needed to tweak
all of my 20+ years of [ohmygod] csh scripts,
sun /bin/sh scripts, rebuild all custom c-src
utils/apps of my own design (hack might be more
appropriate) all the while having to migrating
from bigendian ufs to some other unknown to me
linux file-system. then what about all the
incompatibility messages i see on most fossy
applications ...
it is enough to make me 'hang in there with my
old old old "odd-ball os" but static os' that
i have some arguably reasonable grasp upon.
dunno if i'm right, but the choice seems clear to me
'if it ain't broke don't fix it'.
third part 2: how about linux for sun4u sparc
hardware? i've not found a release or even
a hint that such might be possible without
substantial additional effort.
Olaf Meeuwissen wrote:
Hi ras,
r. a. schmied writes:
i've embedded some more text way down towards the bottom
regarding the AS_CASE(x$host_os,...) call and my solution
history as related to/with solaris 10 sparc and its libusb.
Olaf Meeuwissen wrote:
[...]
By all means share your "hack".
Thanks for sharing!
first off the AS_CASE(x$host_os,...) in configure.ac is
intentionally disabled because of the leading 'x' char;
as x$host_os is never going to match any $host_os variable.
at least that was what i found when i created a case for solaris*.
My bad! Thanks for pointing out this stupidity. The 'x' is prefixed
just in case $host_os is empty. Of course, that should be taken into
account in the globs. :brown_bag: :face_palm:
what this 'disabling' does do is always forces the *) choice
which employs pkg-config to get the data for libusb.
ACK and that was completely unintentional. Fixed in f901462f.
so without the pkg-config pc file for libusb configure failed
UNLESS i pre-set USB_CFLAGS and USB_LIBS on configure environment.
then, because configure then found usb.h it went ahead and
set #define HAVE_LIBUSB 1
i saw/see no way to force configure to define HAVE_LIBUSB_LEGACY
instead, short of re-working configure.ac as i have done.
You mentioned the existence of a libusb-config utility. It was at an
odd-ball location in /usr/sfw/bin/ but if that directory is in your
PATH, then you should use that to get the various variables, without
setting any LIBUSB_* variables in your environment or on the
command-line when running configure.
All you should do is make sure /usr/sfw/bin/ is in your PATH or perhaps
tinker with AC_PATH_PROG to find it.
# See
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/autoconf.html#Generic-Programs
What does running libusb-config produce? IIRC, there are flags to limit
output to LIBS and CFLAGS needed during the build. These are the ones
you need to collect in the configure.ac code. You also want to get the
libusb version from libusb-config if possible to determine which of
HAVE_LIBUSB and HAVE_LIBUSB_LEGACY to set to '1'.
# From your patch I gather your libusb is 0.1.7. That is so old it's
# not funny anymore, BTW. Hmm, I just noticed that our legacy check
# prefers >= 0.1.8 ... :thinking_face: ... over a 10+ year old libusb
# version that you appear to be using. The code comment about 10+ is
# itself will be three years old next month, so 13+ years old libusb.
[...] you saners are going to make a relatively large delta to
configure and friends i figured i try to solve this solaris usblib
problem 'the autotools way'.
:+1:
The autotools are a bit of a steep learning curve :unamused:
[...]
other things about autotools i've learned about the hard way:
for example the current configure setup uses envvars
USB_CFLAGS and USB_LIBS, but the ax_path_generic.m4 and
ax_compare_version.m4 use/create envvars LIBUSB_CFLAGS and
LIBUSB_LIBS. that might be because i'm still a nooby with
autotools, but it still is a wrinkle that really should be
ironed out. i'm sure there are others ....
I'm fairly sure this is caused by differences between libusb-1.0 and
libusb-0.1. The former uses 'libusb' and 'LIBUSB', the latter uses
versions without the 'lib'/'LIB' bits.
FWIW, the sane-backends prefer libusb-1.0.
[...]
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
--
sane-devel mailing list: [email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to [email protected]
