Re: [hpoj-devel] tonight's code changes

[<pa...@rc...>]

Ben "Obi-Wan" Hollingsworth wrote:
> Close, but not quite.  In configure, line 801 uses -x to check for
> libqt.so.
You're pretty brave if you're reading the configure script.  :-)  That file,
in all of its convoluted glory, is actually generated from configure.in by
autoconf.  The corresponding line number in configure.in is 148.

> That won't work on Debian because libqt.so is a symlink
> to libqt.so.2.3.0 (or whatever version you have).  -x fails for
> symlinks.  I changed it to -f and all is well.  I actually found
> that problem last time I installed, but forgot to mention it.
> 
>    if test -x $dir/bin/moc -a \( -f $dir/include/qmainwindow.h -o -f $dir/include/qt/qmainwindow.h \) -a -x $dir/lib/libqt.so -a -z "$HIDE_QT" ; then
> 
> should be:
> 
>    if test -x $dir/bin/moc -a \( -f $dir/include/qmainwindow.h -o -f $dir/include/qt/qmainwindow.h \) -a -f $dir/lib/libqt.so -a -z "$HIDE_QT" ; then
> 
> because:
> 
> # dir /usr/lib/libqt.so*
> lrwxrwxrwx    1 root     root           14 May 31 01:06 /usr/lib/libqt.so -> libqt.so.2.3.0
> lrwxrwxrwx    1 root     root           14 May 31 00:56 /usr/lib/libqt.so.2 -> libqt.so.2.3.0
> lrwxrwxrwx    1 root     root           14 May 31 00:56 /usr/lib/libqt.so.2.3 -> libqt.so.2.3.0
> -rw-r--r--    1 root     root      4943852 May 25 02:28 /usr/lib/libqt.so.2.3.0

That sounds like a bash bug to me, because it's a symlink on my system too
and -x works fine.  According to the bash man page:
-e file -- true if file exists.
-f file -- true if file exists and is a regular file.
-L file -- true if file exists and is a symbolic link.
-x file -- true if file exists and is executable.
Neither -f nor -x claim to either include or exclude symlinks.  Therefore,
it seems to me that -e (the most permissive of all) would be a safer
workaround to detect libqt.so.  Let me know if -e works for you, and I'll
change it to that if it does.

> I seem to remember seeing somewhere when I was setting up all this
> printing & scanning stuff that I should used the 2.2.x kernel instead
> of the 2.4.x kernel.  Is that currently true?  Did it used to be true?
That was true for previous released versions.  Even 0.7 ended up having
trouble with some last-minute changes in 2.4, but there's a patch available
to fix that.

> Do I need to lay off the weed?
Yes, but not for this reason.  :-)

> Will I run into problems if I install 2.4.5?
ptal-mlcd is completely kernel-independent when using it in parallel-port
mode, because all of the signalling is done in user mode.  Unfortunately,
this does impact performance somewhat, so in the future I will look into
adding optional support for the 2.4 ppdev interface, possibly through the
libieee1284 that Tim Waugh is developing.  (Tim: I apologize for not yet
getting a chance to sit down and write up my wish-list for this.  It's on
my TODO list.)

> Also, am I remembering correctly that I no longer need to use the
> kernel parport stuff, assuming all I use my parallel port for is
> accessing my PSC 500?
That is correct.  However, you can still use the "-device /dev/lp0" switch
for ptal-mlcd to ensure that other processes can't open up the parallel port
and interfere with ptal-mlcd's use of the port.  Alternatively, you could
recompile your kernel without parport support, which would pretty much
guarantee that only ptal-mlcd could access it.

> > I'm about to change my BIOS as we discussed earlier, and I'll let you
> > know how it goes.
> 
> Much faster scanning.  Everythings seems to be working well.  I'll
> let you know if problems arise.
Thanks for the success report.  I take it you haven't tried running
"scanimage --test", because that has a tendency to lock up certain models,
including yours.  I'm working on a fix for that problem right now.

David