[EMAIL PROTECTED] wrote:
> Thomas> Hmm... I just found that particular string in libX11.so.3.1.0 and
> Thomas> in libXt.so.3.1.0, under /usr/X11R5/lib. Strace verivies that they
> Thomas> are indeed used, so that's probably where that path comes from.
> Thomas> The vendor is not to blame.
>
>But those don't seem to be loaded by /usr/local/bin/maple/bin/mapleV
>
>$ ldd /usr/local/maple/bin/mapleV
> libm.so.4 (DLL Jump 4.5pl21) => /lib/libm.so.4.6.27
> libc.so.4 (DLL Jump 4.5pl21) => /lib/libc.so.4.6.27
But they're loaded by irisVxm, the graphical front end:
$ ldd irisVxm
libXt.so.3 (DLL Jump 3.1) => /usr/i486-linuxaout/lib/libXt.so.3.1.0
libX11.so.3 (DLL Jump 3.1) => /usr/i486-linuxaout/lib/libX11.so.3.1.0
libc.so.4 (DLL Jump 4.5pl21) => /lib/libc.so.4.7.2
After playing around with 'strings' in the /usr/X11R5/lib directory,
I finally hit upon a workable solution: Do a
$ export XWINHOME=/usr/X11R6
This appears to override the hard-coded paths in the X11R5 compatibility
package.
(Dirk, it might be a good idea to check wether you have something like
this in your environment; another suspect is the XKEYSYMDB
environment variable).
Since I have no idea of how to set an environment variable from
a Debian package (and from which package to do it) I leave it
to more capable hands to reassign this bug to whatever package
is right (xbase, xcompat, or whatever).
--
Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED]
The joy of engineering is to find a straight line on a double
logarithmic diagram.
