January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: LD_LIBRARY_PATH and --rpath 24 years, 10 months

Ulrich Drepper

Martin Buchholz <martin(a)xemacs.org> writes: > - LD_LIBRARY_PATH > - directories specified at link time via -R or --rpath > - the default directories /usr/lib and /lib If Sun does it this way, they are wrong. The standards explicitly say it's the way we've implemented it. You cannot override a RPATH (or nowadays RUNPATH) with LD_LIBRARY_PATH. Read the spcification, it's freely available from SCO's web site. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

4 participants
6 comments

edit-utils 1.44 released 24 years, 10 months

Andreas Jaeger

I've uploaded edit-utils 1.44 to ftp.xemacs.org/pub/xemacs/beta/incoming. The file bookmarks was not usable with XEmacs 21.1.x, I've applied a quick fix from Adrian. I'd like to see a real fix soon. Please test the package and tell me whether it works. I'd like to release it asap. Andreas P.S. Here's the ChangeLog: 2000-01-18 Andreas Jaeger <aj(a)suse.de> * bookmark.el (bookmark-completing-read): Fix patch from 1999-12-21 for XEmacs 21.1.x. Patch by Adrian Aichner <aichner(a)ecf.teradyne.com>. 2000-01-17 Yoshiki Hayashi <t90553(a)mail.ecc.u-tokyo.ac.jp> * bookmark.el (bookmark-menu-popup-paned-menu): Use get-popup-menu-response. 2000-01-14 Yoshiki Hayashi <t90553(a)mail.ecc.u-tokyo.ac.jp> * makesum.el (make-command-summary): Use with-displaying-help-buffer. provide makesum. -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

2 participants
1 comments

Re: [PATCH] bookmark.el of edit-utils 1.43 (completing-read usage error) 24 years, 10 months

Hrvoje Niksic

Andreas Jaeger <aj(a)suse.de> writes: > >>>>> Adrian Aichner writes: > > APA> How about this little patch against bookmark.el in the edit-utils > APA> package? > > APA> diff -u c:\XEmacs\xemacs-packages\lisp\edit-utils\bookmark.el.orig c:\XEmacs\xemacs-packages\lisp\edit-utils\bookmark.el > APA> --- c:\XEmacs\xemacs-packages\lisp\edit-utils\bookmark.el.orig Mon Jan 17 14:49:58 2000 > APA> +++ c:\XEmacs\xemacs-packages\lisp\edit-utils\bookmark.el Mon Jan 17 14:49:58 2000 > APA> ＠＠ -503,9 +503,8 ＠＠ > APA> bookmark-alist > APA> nil > APA> 0 > APA> - nil > APA> - 'bookmark-history > APA> - default))) > APA> + default > APA> + 'bookmark-history))) > APA> (if (string-equal "" str) > APA> (list default) > APA> (list str)))) > > APA> Please advise, > > I'm applying this patch now to fix the package. I hope that > somebody else sends a better patch asap. I'm not sure that patch is right. The DEFAULT argument didn't exist in pre-21.2 XEmacs, and this patch leaves it in. That looks wrong.

1 participants
0 comments

Re: LD_LIBRARY_PATH and --rpath ***please read*** 24 years, 10 months

Hrvoje Niksic

nbecker(a)fred.net writes: > I don't know if anyone noticed my previous post on this subject. I noticed it, and I disagree with it. > As I recall, it was removed because it can cause severe problems. > If an rpath is compiled in to an executable, that is later run in a > different environment, the referenced rpath could contain references > to NFS mounted stuff that is no longer valid, causing severe startup > delays. I would expect XEmacs to notice the location of libraries and use it. If I move the libraries and XEmacs malfunctions because of that, I can't really blame it. Hardcoding library paths in the binary is IMO much better than the alternative, which is building an XEmacs that doesn't work. And it was never removed, except from Linux.

1 participants
0 comments

Re: Yet another X crash in 21.2.26 on Solaris 2.7 24 years, 10 months

Raymond Toy

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 12:54 PM 1/17/00 -0500, Raymond Toy wrote: >> >> Here is the C traceback for yet another crash. I don't really >> remember what I was doing (too much motor memory, and typing faster >> than I was thinking.) Haven't seen this one before. Gutters were >> enabled, if that matters. Andy> This has been reported by many others and I think I have it fixed in CVS. Ok, I guess I missed those reports. I'll wait for the next beta release then. Ray

1 participants
0 comments

Re: 21.2.26 Gutter crash on Solaris 2.7 24 years, 10 months

Raymond Toy

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> --=====================_948191373==_ Andy> Content-Type: text/plain; charset="us-ascii" Andy> Hi Ray, Andy> At 12:35 PM 1/17/00 -0500, Raymond Toy wrote: >> Ok, it happened again. The C traceback is appended below. Andy> Could you try this patch instead of the other one and let me know if it Andy> makes any difference. Patch applied. Hopefully, "no news is good news". :-) Ray

1 participants
0 comments

Yet another X crash in 21.2.26 on Solaris 2.7 24 years, 10 months

Raymond Toy

Here is the C traceback for yet another crash. I don't really remember what I was doing (too much motor memory, and typing faster than I was thinking.) Haven't seen this one before. Gutters were enabled, if that matters. This is a full 21.2.26 tarball with Andy's gutter patch for one of my previously reported crashes. Otherwise, a stock beta 26. Ray #0 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa7638 in fatal_error_signal (sig=10) at emacs.c:276 #2 <signal handler called> #3 0xfeeaf190 in SetValues () from /usr/openwin/lib/libXt.so.4 #4 0xfeeae8ac in XtSetValues () from /usr/openwin/lib/libXt.so.4 #5 0x20bf4c in x_resize_subwindow (ii=0x1aeda80, w=648, h=21) at glyphs-x.c:2295 #6 0x153400 in Fresize_subwindow (subwindow=28236416, width=648, height=21) at glyphs.c:4231 #7 0xb1ee0 in Ffuncall (nargs=3, args=0xffbec934) at eval.c:3175 #8 0x78ef4 in execute_optimized_program (program=0xffbec934 "", stack_depth=3, constants_data=0x59ad10) at bytecode.c:743 #9 0x786bc in funcall_compiled_function (fun=5797976, nargs=1, args=0xffbecc40) at bytecode.c:519 #10 0xb20ac in Ffuncall (nargs=1, args=0xffbecc38) at eval.c:3210 #11 0xb3020 in run_hook_with_args_in_buffer (buf=0x2f7804, nargs=2, args=0xffbecc38, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3661 #12 0xb3150 in va_run_hook_with_args (hook_var=3112380, nargs=1) at eval.c:3674 #13 0x724f0 in Frecord_buffer (buffer=3791872) at buffer.c:1412 #14 0x221284 in Fselect_window (window=22583808, norecord=3110916) at window.c:3250 #15 0xb1ec8 in Ffuncall (nargs=-1, args=0xffbecec4) at eval.c:3175 #16 0x78ef4 in execute_optimized_program (program=0xffbecec4 "", stack_depth=1, constants_data=0xb1e390) at bytecode.c:743 #17 0x786bc in funcall_compiled_function (fun=11613480, nargs=2, args=0xffbed128) at bytecode.c:519 #18 0xb20ac in Ffuncall (nargs=2, args=0xffbed11c) at eval.c:3210 #19 0x78ef4 in execute_optimized_program (program=0xffbed11c "", stack_depth=2, constants_data=0xb1e690) at bytecode.c:743 #20 0x786bc in funcall_compiled_function (fun=11613256, nargs=2, args=0xffbed388) at bytecode.c:519 #21 0xb20ac in Ffuncall (nargs=2, args=0xffbed37c) at eval.c:3210 #22 0x78ef4 in execute_optimized_program (program=0xffbed37c "", stack_depth=2, constants_data=0xa00510) at bytecode.c:743 #23 0x7d3f4 in Fbyte_code (instructions=-4270944, constants=10487040, stack_depth=9) at bytecode.c:2400 #24 0xb1684 in Feval (form=10122324) at eval.c:2975 #25 0xad680 in internal_catch (tag=4183004, func=0xb0dec <Feval>, arg=10122324, threw=0x0) at eval.c:1304 #26 0x79bb4 in execute_rare_opcode (stack_ptr=0xffbedbdc, program_ptr=0xa11733 "\207", opcode=Bcatch) at bytecode.c:1249 #27 0x78c10 in execute_optimized_program (program=0xffbedbe0 "", stack_depth=141, constants_data=0x9cc270) at bytecode.c:653 #28 0x786bc in funcall_compiled_function (fun=9901268, nargs=2, args=0xffbede24) at bytecode.c:519 #29 0xb20ac in Ffuncall (nargs=2, args=0xffbede20) at eval.c:3210 #30 0xb2934 in Fapply (nargs=4, args=0xffbedfc8) at eval.c:3445 #31 0xb2048 in Ffuncall (nargs=2, args=0xffbedfc4) at eval.c:3196 #32 0x78ef4 in execute_optimized_program (program=0xffbedfc4 "", stack_depth=2, constants_data=0x989f10) at bytecode.c:743 #33 0x786bc in funcall_compiled_function (fun=9901100, nargs=4, args=0xffbee228) at bytecode.c:519 #34 0xb20ac in Ffuncall (nargs=4, args=0xffbee214) at eval.c:3210 #35 0x78ef4 in execute_optimized_program (program=0xffbee214 "", stack_depth=4, constants_data=0xb8d610) at bytecode.c:743 #36 0x786bc in funcall_compiled_function (fun=11965008, nargs=1, args=0xffbee480) at bytecode.c:519 #37 0xb20ac in Ffuncall (nargs=1, args=0xffbee478) at eval.c:3210 #38 0x7f8bc in Fcall_interactively (function=9194964, record_flag=3110916, keys=3110916) at callint.c:946 #39 0xb05d0 in Fcommand_execute (cmd=9194964, record=3110916, keys=3110916) at eval.c:2613 #40 0x1080c4 in execute_command_event (command_builder=0x639a80, event=17466508) at event-stream.c:4332 #41 0x108bf0 in Fdispatch_event (event=17466508) at event-stream.c:4643 #42 0x89988 in Fcommand_loop_1 () at cmdloop.c:575 #43 0x896d4 in command_loop_1 (dummy=3110916) at cmdloop.c:490 #44 0xadb34 in condition_case_1 (handlers=2890752, bfun=0x89670 <command_loop_1>, barg=3110916, hfun=0x89b5c <cmd_error>, harg=3110916) at eval.c:1629 #45 0x89c6c in command_loop_2 (dummy=3110916) at cmdloop.c:252 #46 0xad680 in internal_catch (tag=3193172, func=0x89c20 <command_loop_2>, arg=3110916, threw=0x0) at eval.c:1304 #47 0x88ee8 in initial_command_loop (load_me=564256) at cmdloop.c:301 #48 0xa922c in xemacs_21_2_b26_sparc_sun_solaris2_7 (argc=4, argv=0xffbeeddc, envp=0xffbeedf0, restart=0) at emacs.c:1898 #49 0xa9a64 in main (argc=4, argv=0xffbeeddc, envp=0xffbeedf0) at emacs.c:2323

2 participants
1 comments

Re: 21.2.26 Gutter crash on Solaris 2.7 24 years, 10 months

Raymond Toy

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 01:40 PM 1/14/00 -0500, Raymond Toy wrote: >> If this happens again, I'll try to remember what the tabs were. Would >> it be possible to get this info easily out of the core file? Andy> No, but I could do with seeing the stacktrace again to see if its in the Andy> same place. Ok, it happened again. The C traceback is appended below. The tabs were (left-to-right): cmucl-commit Summary cmucl-commit INBOX Summary INBOX Presentation INBOX I'm pretty sure this was the tabs. I clicked on INBOX Summary when the crash happened. In case it matters, gdb says tw->tabs.hilight is: $7 = {core = {self = 0x19cf600, widget_class = 0x19cf800, parent = 0x1a1d98c, xrm_name = 27384372, being_destroyed = 1 '\001', destroy_callbacks = 0x0, constraints = 0x19cff20, x = 1, y = 47, width = 112, height = 65532, border_width = 0, managed = 0 '\000', sensitive = 1 '\001', ancestor_sensitive = 1 '\001', event_table = 0x1286620, tm = {translations = 0x0, proc_table = 0x1a9a0a0, current_state = 0x0, lastEventTime = 0}, accelerators = 0x0, border_pixel = 0, border_pixmap = 2, popup_list = 0x0, num_popups = 0, name = 0x6c640a "INBOX Summary", screen = 0x62ec00, colormap = 52, window = 130028052, depth = 24, background_pixel = 13026763, background_pixmap = 2, visible = 1 '\001', mapped_when_managed = 0 '\000'}} Ray #0 0xfeb16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa7638 in fatal_error_signal (sig=11) at emacs.c:276 #2 <signal handler called> #3 0xfeeb217c in _XtWindowedAncestor () from /usr/openwin/lib/libXt.so.4 #4 0xfeeab36c in XtWindowOfObject () from /usr/openwin/lib/libXt.so.4 #5 0x23cefc in XawTabsSetHighlight (t=0x1382a00, w=0x13d2600) at xlwtabs.c:1310 #6 0x23ce84 in XawTabsSetTop (w=0x13d2600, callCallbacks=1) at xlwtabs.c:1292 #7 0x23c88c in TabsSelect (w=0x1382a00, event=0xd, params=0x0, num_params=0xfeefa124) at xlwtabs.c:1073 #8 0xfeec1c30 in HandleActions () from /usr/openwin/lib/libXt.so.4 #9 0xfeec0a50 in HandleSimpleState () from /usr/openwin/lib/libXt.so.4 #10 0xfeec0528 in _XtTranslateEvent () from /usr/openwin/lib/libXt.so.4 #11 0xfeec045c in XtDispatchEventToWidget () from /usr/openwin/lib/libXt.so.4 #12 0xfeebfce8 in _XtDefaultDispatcher () from /usr/openwin/lib/libXt.so.4 #13 0xfeebf810 in XtDispatchEvent () from /usr/openwin/lib/libXt.so.4 #14 0xfeec2fa0 in XtAppProcessEvent () from /usr/openwin/lib/libXt.so.4 #15 0x1fdbd8 in emacs_Xt_next_event (emacs_event=0xdce8ec) at event-Xt.c:2396 #16 0xffa7c in event_stream_next_event (event=0xdce8ec) at event-stream.c:566 #17 0x102b00 in next_event_internal (target_event=14477548, allow_queued=1) at event-stream.c:2021 #18 0x103250 in Fnext_event (event=14477548, prompt=3110916) at event-stream.c:2238 #19 0x89978 in Fcommand_loop_1 () at cmdloop.c:566 #20 0x896d4 in command_loop_1 (dummy=3110916) at cmdloop.c:490 #21 0xadb34 in condition_case_1 (handlers=2890752, bfun=0x89670 <command_loop_1>, barg=3110916, hfun=0x89b5c <cmd_error>, harg=3110916) at eval.c:1629 #22 0x89c6c in command_loop_2 (dummy=3110916) at cmdloop.c:252 #23 0xad680 in internal_catch (tag=3193172, func=0x89c20 <command_loop_2>, arg=3110916, threw=0x0) at eval.c:1304 #24 0x88ee8 in initial_command_loop (load_me=564256) at cmdloop.c:301 #25 0xa922c in xemacs_21_2_b26_sparc_sun_solaris2_7 (argc=4, argv=0xffbeeddc, envp=0xffbeedf0, restart=0) at emacs.c:1898 #26 0xa9a64 in main (argc=4, argv=0xffbeeddc, envp=0xffbeedf0) at emacs.c:2323

2 participants
2 comments

xemacs-base 1.36 released 24 years, 10 months

Andreas Jaeger

I've uploaded a new xemacs-base package to ftp.xemacs.org/pub/xemacs/packages. The only difference to the last version is the addition of regexp-opt. The file has been moved from xemacs-devel as already announced in the last mail - but the package missed that file :-(. Sorry about that. The tarballs are ok. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

Re: Status of xemacs packages 24 years, 10 months

Norbert Koch

Ray Lehtiniemi <rayl(a)optitech.com> writes: > make-mode dies looking for 'regexp-opt' on my 21.1.8 with newest > packages. it seems that 'regexp-opt' was moved from xemacs-devel to > xemacs-base, but only the xemacs-devel package is available on > ftp.xemacs.org? There's an xemacs-base package on ftp.xemacs.org: xemacs-base-1.35-pkg.tar.gz from Jan 11. But there's only a regi (regular expression interpreter engine) in xemacs-base. Don't know, whether this is what you're looking for, presumably not. norbert.

3 participants
2 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta January 2000