Samuel, thanks for bringing me into this discussion! I'm
not on the
blinux-list redhat.com, so the conversation snippet below is the
only
context I have. I'm CC'ing the orca-listgnome.org
list since that's
where the majority of Orca discussion should happen.
The main issue we're dealing with here is a substantial
change to BrlAPI
from BrlTTY v3.7.2 (BrlAPI 0.4.1) to BrlTTY v3.8 (BrlAPI
0.5). It's
generally for the better, since BrlAPI 0.5 now includes
Python bindings
(THANKS!!!!), but it's also not smooth because binary
incompatibilities
were introduced.
In Orca, we're trying to make sure we are flexible enough to
support
both versions during this transition period in BrlTTY, and
we also don't
want to require people to recompile/reinstall Orca when they
move from
one version of BrlTTY to the next. In general, I think
we're pretty
close (the GNOME CVS HEAD code works great for me and many
others). One
thing that slipped through the cracks, however, was the
check in
configure.in. It's really only a warning message -- Orca
*should*
automatically find and use the right version of BrlAPI at
run time,
assuming BrlTTY/BrlAPI are appropriately installed.
Here are the details:
The BrlAPI check in Orca's configure.in currently looks like
the
following:
AC_CHECK_LIB(brlapi, brlapi_initializeConnection,,
[brlapi_available="no"; AC_MSG_WARN(Could not find
libbrlapi.so - you
need BrlTTY >= 3.7.2 and BrlAPI >= 0.4.1 installed to
use braille)])
All it's doing is attempting to verify that libbrlapi.so has
the
brlapi_initializeConnection symbol in it. If libbrlapi.so
cannot be
found, or the symbol doesn't exist, then the configure
assumes BrlAPI is
not available and issues a warning message.
In looking at the latest BrlAPI code, it looks like
brlapi_initializeConnection was demoted from a method to a
macro. This
incompatible change seems to be the source of the failures
since the
brlapi_initializeConnection symbol will no longer be in the
libbrlapi.so.
We can use this incompatible binary change to our advantage,
however:
upon detecting this failure, we can check to see if the
BrlAPI Python
bindings are present. This will give us a rough idea of
which version
of BrlAPI is available (i.e., the one without Python
bindings or the one
with Python bindings) and if Orca can get to it or not. I
just checked
in some changes to Orca's configure.in to do this,
eliminating the
warning message if one or the other versions of BrlAPI is
present.
With respect to /var/log/Xorg.0.log, where would you suggest
checking
for it with respect to XFree86_VT and WINDOWPATH?
Will
On Mon, 2006-12-11 at 11:17 +0100, Samuel Thibault wrote:
> coscellmail.batol.net, le Mon 11 Dec 2006 17:54:34 +0800, a
écrit :
> > >grep VT /var/log/Xorg.0.log
> >
> > (--) using VT number 7
>
> Ok. Please always check that.
>
> William, I fail to see where the problem comes from.
Does this warning
> disable brlapi via the official python binding too?
>
> configure: WARNING: Could not find libbrlapi.so - you
need BrlTTY >= 3.7.2 and BrlAPI >= 0.4.1 installed to
use braille
>
> (the python binding itself seems to work fine: calling
>
> import brlapi
>
> from python works, and he says he doesn't get any error
message from
> orca)
>
> Samuel
_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
|
Else, assuming 7 should be fine in most cases.
Samuel
_______________________________________________
Orca-list mailing list
Orca-list