12:37 p.m.
ok, i wanted to show you i had problems with gutters when it came to
creating a second frame, but xemacs crashed without leaving me
enough time.
but i have several problems with the latest cvs 21.2 :
i built it with ./configure --with-mule
and when i run it it says:
rock stephane 13:14 ~ > xemacs&
[1] 12952
rock stephane 13:14 ~ > xemacs: Symbol `toggleClassRec' has different size in
shared object, consider re-linking
xemacs: Symbol `labelClassRec' has different size in shared object, consider
re-linking
---------
ok, that and the fact that when i try to launch a gnuclient with a file
as argument, it just crashes and gives me:
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Please report this bug by running the send-pr script included
with XEmacs, or selecting `Send Bug Report' from the help menu.
As a last resort send ordinary email to `crashes(a)xemacs.org'.
*MAKE SURE* to include the information in the command
M-x describe-installation.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started the editor, or maybe in your home
directory), and type
gdb /usr/local/bin/xemacs core
then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB. A similar procedure should work for all of
these. Ask your system administrator if you need more help.)
Lisp backtrace follows:
# bind (frame-being-created)
make-frame(nil #<x-device on "rock:11.0" 0x2b80>)
# bind (device dest-frame new-frame old-device-num quick view flags list type)
gnuserv-edit-files((x "rock:11.0") ((1 .
"/tmp/mutt-rock-18306-2")))
eval((gnuserv-edit-files (quote (x "rock:11.0")) (quote (...))))
byte-code("..." [eval read-from-string gnuserv-string header] 4)
# (condition-case ... . ((error (byte-code "ÀpÂ
\"ÅrÆ
＠
A\"" ... 3)) (quit
(byte-code "ÀpÂ
\"ÅrÆÇÅ\"" ... 3))))
# bind (header string proc)
gnuserv-process-filter(#<process "gnuserv" pid 18304 state:run> "5
(gnuserv-edit-files '(x \"rock:11.0\") '((1 .
\"/tmp/mutt-rock-18306-2\")))c")
# (condition-case ... . error)
# bind (inhibit-quit)
# (condition-case ... . error)
# (catch top-level ...)
[1] Segmentation fault xemacs
------------
you guys want a stack trace ?
oh well, it does not seem to happen when i call gnuclient with no
argument.
ah, also i had a comment on the gutter:
i load a file, then i load another file with C-x 5 f
and the new frame has the gutter all painted with my background
color and no text is visible on the gutter.
first frame screenshot:
http://tanglefoot.lunatech.com/~stephane/xemacs-gutter1.gif
second one:
http://tanglefoot.lunatech.com/~stephane/xemacs-gutter2.gif
is it normal ? do you want more info?
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
1:09 p.m.
New subject: gnuclient crash
ok, here's the deal:
when i launch gnuclient with a filename it crashes, and this is the
result of 'where' in gdb:
#0 0x40304031 in kill () from /lib/libc.so.6
#1 0x8092a79 in fatal_error_signal (sig=11) at emacs.c:276
#2 0x402bef3c in pthread_sighandler () from /lib/libpthread.so.0
#3 0x40303f68 in __restore () from /lib/libc.so.6
#4 0x80cfffb in IMInstantiateCallback (dpy=0x88a6e38,
client_data=0x89a24f0 "\034¸;＠`\n¥\bQP", call_data=0x0)
at input-method-xlib.c:253
#5 0x401e5112 in _XimRegisterIMInstantiateCallback () from
/usr/X11R6/lib/libX11.so.6
#6 0x401bbf50 in XRegisterIMInstantiateCallback () from
/usr/X11R6/lib/libX11.so.6
#7 0x80d031d in XIM_init_frame (f=0x89a24f0) at input-method-xlib.c:338
#8 0x81dd48d in x_popup_frame (f=0x89a24f0) at frame-x.c:2070
#9 0x81ded3c in x_init_frame_3 (f=0x89a24f0) at frame-x.c:2189
#10 0x811ecc1 in Fmake_frame (props=137402748, device=143977120) at
frame.c:473
#11 0x8099119 in Ffuncall (nargs=3, args=0xbfffe788) at eval.c:3189
#12 0x8063c86 in execute_optimized_program (
program=0x88c2564 "À\211\031\032ÃÄ\r\"\210Æ
G\036\aÀ\036\bÉ\016\n!«\t\016\n\016\013＠!ª\003\016\n\036\fÍ\016\f!«\aÎ\016\f!ª5\016\f¬/\016\013＠Ïa«\tÐÑ\016\013A\"ª\"\016\013＠Òa«\tÓ\016\013A＠!ª\023\016\013＠Ôa«\005Õ
ª\bÖ×!ª\003Ø
\036\031Í\016\f!«\005\016\fª\022\016\f¬\fÚ\016\e\016\031\"\211\026\bª\003Ü
\036\035Þß\016 À\016\031\016\b%\036!À\026 \016\aÆ
GU¬\b\016\031\016\"B\026\"ã\016\035!«\006ä\016\035!\210\016%\203¯",
stack_depth=7, constants_data=0x839c480) at bytecode.c:747
#13 0x8063820 in funcall_compiled_function (fun=139675056, nargs=0,
args=0xbfffe828) at bytecode.c:523
#14 0x8098900 in Feval (form=144556444) at eval.c:3045
#15 0x8099105 in Ffuncall (nargs=2, args=0xbfffe99c) at eval.c:3189
#16 0x8063c86 in execute_optimized_program (program=0xbfffe9ec
"ÀÁ\n\013A\"＠!\207", stack_depth=4, constants_data=0x86014a0)
at bytecode.c:747
#17 0x8067864 in Fbyte_code (instructions=141018244,
constants=140514448, stack_depth=9) at bytecode.c:2406
#18 0x809856d in Feval (form=140231308) at eval.c:2986
#19 0x8095a6b in condition_case_1 (handlers=140288896, bfun=0x8097b20
<Feval>, barg=140231308,
hfun=0x8095af0 <run_condition_case_handlers>, harg=140991780) at
eval.c:1640
#20 0x8095faa in condition_case_3 (bodyform=140231308, var=140991780,
handlers=140288896) at eval.c:1718
#21 0x80647d4 in execute_rare_opcode (stack_ptr=0xbfffec90,
program_ptr=0x863cd99 "\210Ë\211\020)\207ÌÍ\b\"\210Ë\211\020\207H",
opcode=Bcondition_case) at bytecode.c:1272
#22 0x8063a08 in execute_optimized_program (
program=0x863cd7c
"\b\tP\020ÂÃ\b\"\"ÂÄ\b\"«\024Å\b!\211\036\006＠\026\aÈÉÊ\217\210Ë\211\020)\207ÌÍ\b\"\210Ë\211\020\207H",
stack_depth=4, constants_data=0x83a6b50) at bytecode.c:657
#23 0x8063820 in funcall_compiled_function (fun=139674916, nargs=2,
args=0xbfffed94) at bytecode.c:523
#24 0x80992a3 in Ffuncall (nargs=3, args=0xbfffed90) at eval.c:3221
#25 0x809af32 in catch_them_squirmers_call2 (cons=144633036) at
eval.c:3851
#26 0x8095a6b in condition_case_1 (handlers=137402844, bfun=0x809ad70
<catch_them_squirmers_call2>, barg=144633036,
hfun=0x809e100 <caught_a_squirmer>, harg=137605768) at eval.c:1640
#27 0x809b255 in call2_trapping_errors (warning_string=0x8264f24 "Error
in process filter", function=140991732,
object1=140512424, object2=141122956) at eval.c:4421
#28 0x8176d4c in read_process_output (proc=140512424) at process.c:846
#29 0x80e9086 in execute_internal_event (event=143823804) at
event-stream.c:2962
#30 0x80ed066 in Fdispatch_event (event=143823804) at
event-stream.c:4689
#31 0x807469b in Fcommand_loop_1 () at cmdloop.c:578
#32 0x80748ff in command_loop_1 (dummy=137402748) at cmdloop.c:493
#33 0x8095a6b in condition_case_1 (handlers=137402844, bfun=0x80748b0
<command_loop_1>, barg=137402748,
hfun=0x8073780 <cmd_error>, harg=137402748) at eval.c:1640
#34 0x80749f2 in command_loop_2 (dummy=137402748) at cmdloop.c:255
#35 0x809d6d9 in internal_catch (tag=137477180, func=0x80749c0
<command_loop_2>, arg=137402748, threw=0x0) at eval.c:1315
#36 0x8073c7c in initial_command_loop (load_me=137402748) at
cmdloop.c:304
#37 0x8090ced in xemacs_21_2_b19_i686_pc_linux (argc=1, argv=0xbffff6f4,
envp=0xbffff6fc, restart=0) at emacs.c:1764
#38 0x8092caf in main (argc=1, argv=0xbffff6f4, envp=0xbffff6fc) at
emacs.c:2189
#39 0x402fe212 in __libc_start_main () from /lib/libc.so.6
seems it crahes while instanciating the frame ?
hope this helps.
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
12:10 p.m.
New subject: gnuclient crash TOO OFTEN!
shame to me, xemacs is just crashing so often when i call gnuclient
that i even had to setenv EDITOR vi !
i'm really saddened by this :(
is anybody else using gnuclient and havind problems ?
basicly a call to gnuclient crashes the entire xemacs running.
got a lisp backtrace :
# bind (frame-being-created)
make-frame(nil #<x-device on ":0.0" 0x5f97>)
# bind (device dest-frame new-frame old-device-num quick view flags
# list type)
gnuserv-edit-files((x ":0.0") ((1 . "/tmp/mutt-rock-2832-1")))
eval((gnuserv-edit-files (quote (x ":0.0")) (quote (...))))
byte-code("..." [eval read-from-string gnuserv-string header] 4)
# (condition-case ... . ((error (byte-code "ÀpÂ
\"ÅrÆ
＠
A\"" ... 3))
(quit (byte
-code "ÀpÂ
\"ÅrÆÇÅ\"" ... 3))))
# bind (header string proc)
gnuserv-process-filter(#<process "gnuserv" pid 2510 state:run> "5
(gnuserv-edi
t-files '(x \":0.0\") '((1 .
\"/tmp/mutt-rock-2832-1\")))c")
# (condition-case ... . error)
# bind (inhibit-quit)
# (condition-case ... . error)
# (catch top-level ...)
[1] + Segmentation fault xemacs (core dumped)
and this is the output of gdb :
(gdb) where
#0 0x402eb0a1 in kill () from /lib/libc.so.6
#1 0x8093cf4 in fatal_error_signal (sig=11) at emacs.c:276
#2 0x402a5edc in pthread_sighandler () from /lib/libpthread.so.0
#3 0x402eafd8 in __restore () from /lib/libc.so.6
#4 0x80d1c17 in IMInstantiateCallback (dpy=0x8bb38c0,
client_data=0x8afc7b0 "\0340:＠\220ǯ\b¨_", call_data=0x0)
at input-method-xlib.c:253
#5 0x401cc112 in _XimRegisterIMInstantiateCallback ()
from /usr/X11R6/lib/libX11.so.6
#6 0x401a2f50 in XRegisterIMInstantiateCallback ()
from /usr/X11R6/lib/libX11.so.6
#7 0x80d1f6e in XIM_init_frame (f=0x8afc7b0) at input-method-xlib.c:338
#8 0x81dce08 in x_popup_frame (f=0x8afc7b0) at frame-x.c:2070
#9 0x81de791 in x_init_frame_3 (f=0x8afc7b0) at frame-x.c:2189
#10 0x8120d53 in Fmake_frame (props=137394140, device=146727680) at
frame.c:473
#11 0x809a49a in Ffuncall (nargs=3, args=0xbfffe2d8) at eval.c:3189
#12 0x8064547 in execute_optimized_program (
program=0x87baa8c "À\211\031\032ÃÄ\r\"\210Æ
G\036\aÀ\036\bÉ\016\n!«\t\016\n\016\013＠!ª\003\016\n\036\fÍ\016\f!«\aÎ\016\f!ª5\016\f¬/\016\013＠Ïa«\tÐÑ\016\013A\"ª\"\016\013＠Òa«\tÓ\016\013A＠!ª\023\016\013＠Ôa«\005Õ
ª\bÖ×!ª\003Ø
\036\031Í\016\f!«\005\016\fª\022\016\f¬\fÚ\016\e\016\031\"\211\026\bª\003Ü
\036\035Þß\016 À\016\031\016\b%\036!À\026 \016\aÆ
GU¬\b\016\031\016\"B\026\"ã\016\035!«\006ä\016\035!\210\016%\203¯",
stack_depth=7, constants_data=0x86352c8) at bytecode.c:747
#13 0x8064119 in funcall_compiled_function (fun=139667116, nargs=2,
args=0xbfffe3b4) at bytecode.c:523
#14 0x8099c6f in Feval (form=145923016) at eval.c:3045
#15 0x809a487 in Ffuncall (nargs=2, args=0xbfffe618) at eval.c:3189
#16 0x8064547 in execute_optimized_program (
program=0xbfffe694 "ÀÁ\n\013A\"＠!\207çÿ¿Xæÿ¿", stack_depth=4,
constants_data=0x85b4208) at bytecode.c:747
#17 0x80683a0 in Fbyte_code (instructions=141012532,
constants=140198392,
stack_depth=9) at bytecode.c:2406
#18 0x8099962 in Feval (form=140306204) at eval.c:2986
#19 0x8096dce in condition_case_1 (handlers=140309920, bfun=0x8098f50
<Feval>,
barg=140306204, hfun=0x8096e50 <run_condition_case_handlers>,
harg=140985940) at eval.c:1640
#20 0x8097345 in condition_case_3 (bodyform=140306204, var=140985940,
handlers=140309920) at eval.c:1718
#21 0x806508d in execute_rare_opcode (stack_ptr=0xbfffea80,
program_ptr=0x895cbf9 "\210Ë\211\020)\207ÌÍ\b\"\210Ë\211\020\207",
opcode=Bcondition_case) at bytecode.c:1272
#22 0x80642eb in execute_optimized_program (
program=0x895cbdc
"\b\tP\020ÂÃ\b\"\"ÂÄ\b\"«\024Å\b!\211\036\006＠\026\aÈÉÊ\217\210Ë\211\020)\207ÌÍ\b\"\210Ë\211\020\207",
stack_depth=4,
constants_data=0x85d8880) at bytecode.c:657
#23 0x8064119 in funcall_compiled_function (fun=139666976, nargs=2,
args=0xbfffebf0) at bytecode.c:523
#24 0x809a5e2 in Ffuncall (nargs=3, args=0xbfffebec) at eval.c:3221
#25 0x809c37d in catch_them_squirmers_call2 (cons=145961840) at
eval.c:3851
#26 0x8096dce in condition_case_1 (handlers=137394236,
bfun=0x809c1b4 <catch_them_squirmers_call2>, barg=145961840,
hfun=0x809f614 <caught_a_squirmer>, harg=137597128) at eval.c:1640
#27 0x809c6ef in call2_trapping_errors (
warning_string=0x8262d64 "Error in process filter",
function=140985892,
object1=140979608, object2=143096252) at eval.c:4421
#28 0x817957c in read_process_output (proc=140979608) at process.c:846
#29 0x80eab49 in execute_internal_event (event=146733196)
at event-stream.c:2962
#30 0x80ee779 in Fdispatch_event (event=146733196) at
event-stream.c:4689
#31 0x8075225 in Fcommand_loop_1 () at cmdloop.c:578
#32 0x80754cd in command_loop_1 (dummy=137394140) at cmdloop.c:493
#33 0x8096dce in condition_case_1 (handlers=137394236,
bfun=0x8075474 <command_loop_1>, barg=137394140,
hfun=0x807553c <cmd_error>, harg=137394140) at eval.c:1640
#34 0x807562f in command_loop_2 (dummy=137394140) at cmdloop.c:255
#35 0x809ecec in internal_catch (tag=137468572,
func=0x80755f0 <command_loop_2>, arg=137394140, threw=0x0) at
eval.c:1315
#36 0x8074813 in initial_command_loop (load_me=137394140) at
cmdloop.c:304
#37 0x8091ebe in xemacs_21_2_b19_i686_pc_linux (argc=1, argv=0xbffff784,
envp=0xbffff78c, restart=0) at emacs.c:1764
#38 0x8093f20 in voodoo_free_hook (mem=0x1) at emacs.c:2189
#39 0x402e5222 in __libc_start_main () from /lib/libc.so.6
---------
but my most important question is: how do i get something close to file
name or even line number in a lisp backtrace ?
i'm still getting into C and all i saw from the C backtrace is that it
caught a sigsegv, so i wanted to look into the lisp backtrace, but
really i dunno where to look as no indication as to the origin of the
line dumped is given.
i am going to work on this problem even if it means taking years from me
to know all about C, because i hate having my whole xemacs session crash
when i want to send a mail. it is not acceptable for me.
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
4:27 p.m.
New subject: gnuclient crash TOO OFTEN!
Stef Epardaud <stef(a)lunatech.com> writes:
shame to me, xemacs is just crashing so often when i call gnuclient
that i even had to setenv EDITOR vi !
i'm really saddened by this :(
is anybody else using gnuclient and havind problems ?
basicly a call to gnuclient crashes the entire xemacs running.
You seem to be running 21.2.19 on Linux box.
Could you let me know your environment both xemacs and gnuclient?
Especially with operating system, $LANG, $LANGUAGE and whatever you
modified or added to the system out of the box.
Anyhow, when you built it with `--input-method=no' as Jan mentioned,
then the problem will go away.
and this is the output of gdb :
(gdb) where
#0 0x402eb0a1 in kill () from /lib/libc.so.6
#1 0x8093cf4 in fatal_error_signal (sig=11) at emacs.c:276
#2 0x402a5edc in pthread_sighandler () from /lib/libpthread.so.0
#3 0x402eafd8 in __restore () from /lib/libc.so.6
#4 0x80d1c17 in IMInstantiateCallback (dpy=0x8bb38c0,
client_data=0x8afc7b0 "\0340:＠\220ǯ\b¨_", call_data=0x0)
at input-method-xlib.c:253
#5 0x401cc112 in _XimRegisterIMInstantiateCallback ()
from /usr/X11R6/lib/libX11.so.6
#6 0x401a2f50 in XRegisterIMInstantiateCallback ()
from /usr/X11R6/lib/libX11.so.6
I know we need to purify `input-method-xlib.c'.
The XIM and XIC should be simplified. It is not difficult.
* Register an XIM when the device was initialized in XIM_init_device.
* Initialize an XIC when the frame was poped up in XIM_init_frame.
* Disable all XICs for frames when the XIM was unregistered in
IMDestroyCallback.
* Enable all XICs for frames when the XIM was enabled in
IMInstantiateCallback.
I'm sorry I have little time to do it right now, until 27th of this
month...
-- kazz
2:35 p.m.
New subject: gutter problems : more.
just noticed something funny with the gutter:
i'm using wmaker but i don't think it's related.
if you don't use backingstore and move a window over the gutter part of
XEmacs, well, refresh rate is so slow that it can take minutes of
successive refreshments to keep up with the number of requests stacked.
that is: it does not repaint fast enough i think, whereas the rest of
the frame is repainted correctly, and does not stack all repaint
requests.
result is that it blinks for several seconds after i moved a window over
xemacs.
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
3:51 p.m.
New subject: gutter problems : more.
At 03:35 PM 8/17/99 +0200, Stef Epardaud wrote:
just noticed something funny with the gutter:
i'm using wmaker but i don't think it's related.
if you don't use backingstore and move a window over the gutter part of
XEmacs, well, refresh rate is so slow that it can take minutes of
successive refreshments to keep up with the number of requests stacked.
that is: it does not repaint fast enough i think, whereas the rest of
the frame is repainted correctly, and does not stack all repaint
requests.
result is that it blinks for several seconds after i moved a window over
xemacs.
This is a general problem with subwindows. There is code that stops it
happening infinitely, but there are no optimizations. Better safe than sorry.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
2:51 p.m.
At 01:37 PM 8/17/99 +0200, Stef Epardaud wrote:
rock stephane 13:14 ~ > xemacs: Symbol `toggleClassRec' has
different size
in
shared object, consider re-linking
xemacs: Symbol `labelClassRec' has different size in shared object, consider
re-linking
Are you using Athena 3d? Whatever ,you are likely to have a version
mismatch between the headers you are using and the library (Xaw or Xm or
Xaw3d).
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
5:28 p.m.
New subject: athena 3d
On Tue, Aug 17, 1999 at 02:51:24PM +0100, Andy Piper wrote:
At 01:37 PM 8/17/99 +0200, Stef Epardaud wrote:
>rock stephane 13:14 ~ > xemacs: Symbol `toggleClassRec' has different size
in
>shared object, consider re-linking
>xemacs: Symbol `labelClassRec' has different size in shared object, consider
>re-linking
Are you using Athena 3d? Whatever ,you are likely to have a version
mismatch between the headers you are using and the library (Xaw or Xm or
Xaw3d).
yes indeed,
if i want to link xemacs and not get those warnings everytime i use it,
i have to uninstall athena3d .
if ever it is installed it uses it instead of athena and gives those
mistakes.
is it related to XEmacs, or to my installation of athena 3d ?
and is it possible to tell 'configure' to use normal athena, even if
athena 3d is installed ? (this soulds like a stupid question but i could
not figure it out)
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
10:11 a.m.
New subject: athena 3d
At 06:28 PM 8/17/99 +0200, Stef Epardaud wrote:
yes indeed,
if i want to link xemacs and not get those warnings everytime i use it,
i have to uninstall athena3d .
if ever it is installed it uses it instead of athena and gives those
mistakes.
is it related to XEmacs, or to my installation of athena 3d ?
and is it possible to tell 'configure' to use normal athena, even if
athena 3d is installed ? (this soulds like a stupid question but i could
not figure it out)
Although Athena3d is link compatible with Athena, the core widget
structures are different sizes in Athena3d so if you compile with the
Athena3d library you need to use the Athena3d headers as well.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
7:33 p.m.
New subject: athena 3d
Stef Epardaud wrote:
> >rock stephane 13:14 ~ > xemacs: Symbol
`toggleClassRec' has different size
> in
> >shared object, consider re-linking
> >xemacs: Symbol `labelClassRec' has different size in shared object, consider
> >re-linking
>
> Are you using Athena 3d? Whatever ,you are likely to have a version
> mismatch between the headers you are using and the library (Xaw or Xm or
> Xaw3d).
yes indeed,
if i want to link xemacs and not get those warnings everytime i use it,
i have to uninstall athena3d .
if ever it is installed it uses it instead of athena and gives those
mistakes.
is it related to XEmacs, or to my installation of athena 3d ?
It's related to the fact that Xaw3d isn't entirely compatible with
Xaw. The Xaw3d versions of the subclasses of Widget and WidgetClass
have extra fields, so the field offsets don't match.
The two are compatible for applications which only ever access Widgets
via Xt functions. They aren't compatible for code which accesses the
fields of a Widget directly (this should only be done by Widget
subclasses, although some broken applications also do this).
If you wish to use both, you can either:
a) Install Xaw3d as libXaw3d.so.* rather than libXaw.so.*. This
requires that applications are compiled for a specific version.
b) Install Xaw3d as libXaw.so.* but in a different directory to the
real libXaw.so.*. You can then determine which version to use by
setting LD_LIBRARY_PATH appropriately (e.g. from a wrapper script).
--
Glynn Clements <glynn(a)sensei.co.uk>
9227
days inactive
9230
days old
9 comments
4 participants
participants (4)
-
Andy Piper -
Glynn Clements -
Kazuyuki IENAGA -
Stef Epardaud