[BRLTTY] Library dependencies of driver modules
mlang
mlang at delysid.org
Tue Nov 15 13:09:00 EST 2005
Hi.
Can anyone explain the deeper root cause of the following "problem"
I observed during work on the debian package for brltty 3.7?
x2:/usr/src/brltty-3.7# ./configure
[...]
execute-root:
install-root:
libdir: /lib
sysconfdir: /etc
program-directory: /bin
library-directory: /lib/brltty
data-directory: /etc/brltty
manpage-directory: /usr/share/man
include-directory: /usr/include/brltty
compiler-prefix:
init-path:
api: yes
api-parameters:
gui-toolkit-package: Xaw
preferences-menu: yes
table-selection: yes
learn-mode: yes
contracted-braille: yes
beeper-support: yes
pcm-support: yes
midi-support: yes
fm-support: yes
pm-configfile: yes
gpm: no
standalone-programs: no
usb-support: yes
bluetooth-support: yes
libbraille-root:
external-braille-drivers: al at ba bd bl bm bn cb ec eu fs ht lt mb md mn pm tn ts tt vd vo vr vs xw
internal-braille-drivers:
braille-parameters:
braille-device:
text-table: text.nabcc.tbl
attributes-table: attributes.tbl
speech-support: yes
flite-root: /usr
flite-language: usenglish
flite-lexicon: cmulex
flite-voice: cmu_us_kal16
mikropuhe-root:
swift-root:
theta-root:
viavoice-root:
external-speech-drivers: al bl cb es fl fv gs
internal-speech-drivers:
speech-parameters:
external-screen-drivers: lx sc
internal-screen-drivers:
screen-parameters:
screen-driver: lx
x2:/usr/src/brltty-3.7# make -j2
[...]
x2:/usr/src/brltty-3.7# ldd Programs/brltty
linux-gate.so.1 => (0xffffe000)
libXaw.so.8 => /usr/X11R6/lib/libXaw.so.8 (0x55572000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x555cd000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x5561c000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x55625000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x5563c000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x55708000)
libc.so.6 => /lib/tls/libc.so.6 (0x5571a000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x55851000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x55855000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x5586a000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x55878000)
libXp.so.6 => /usr/X11R6/lib/libXp.so.6 (0x5588f000)
/lib/ld-linux.so.2 (0x55555000)
x2:/usr/src/brltty-3.7# ldd lib/libbrlttybxw.so
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/tls/libc.so.6 (0x55560000)
/lib/ld-linux.so.2 (0x56555000)
x2:/usr/src/brltty-3.7# ldd lib/libbrlttysfl.so
linux-gate.so.1 => (0xffffe000)
libflite_cmu_us_kal16.so.1 => /usr/lib/libflite_cmu_us_kal16.so.1 (0x55558000)
libflite_cmulex.so.1 => /usr/lib/libflite_cmulex.so.1 (0x559d0000)
libflite_usenglish.so.1 => /usr/lib/libflite_usenglish.so.1 (0x55bde000)
libflite.so.1 => /usr/lib/libflite.so.1 (0x55bf3000)
libm.so.6 => /lib/tls/libm.so.6 (0x55c15000)
libc.so.6 => /lib/tls/libc.so.6 (0x55c3b000)
/lib/ld-linux.so.2 (0x56555000)
Is there a way to fix this, and could we perhaps do a 3.7.1 including
this fix, if it exists? Basically, the fact that X11 library dependencies
are chained to the brltty executable makes smart multibinary
packaging basically impossible. My plan was to make a brltty-flite
and brltty-x11 package which would only contain the specific driver
modules (and the resulting dependencies) and therefore eliminate X11 and
FestivalLite library dependencies from the main brltty package such that a
minimal system with brltty on it (no X libs, no gimmicks) could still
be installed while keeping the new and shiny brltty features
for those users who want to use them. The same applies for the
atspi screen driver, I actually didnt check yet if that is well
behaved. The fact that in the libbrlttysfl.so case the
dependencies are right makes me belief this can be fixed somehow.
--
CYa,
Mario
More information about the BRLTTY
mailing list