February 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Could people test out the gtk-xemacs-21-2 branch? 23 years, 11 months

William M. Perry

I just committed the changes to the 'generic' XEmacs files, so that we can test whether there will be any badness if people build --with-gtk=no (the default). There seems to be a CVS lock right now, and I forgot to check in the configure script, but you can regenerate it with 'autoconf' without a problem. I am going to try and update my ancient 21.2 port to the current stuff sometime tomorrow. I don't think it will be 'runnable', but the code would at least be there. Here's the message from CVS if any intrepid CVS admins want to fix it. :) cvs server: [20:05:18] waiting for martinb's lock in /usr/CVSroot/XEmacs/xemacs I hope to have this done in the next few days while the wife is scuba diving. And she thinks _she_ is the one who will be having a good time. :) -Bill P.

3 participants
8 comments

Re: font-lock-after-change function unbearably slow; Ben change? 23 years, 11 months

Raymond Toy

>>>>> "Chris" == Chris Holt <xris(a)transmeta.com> writes: >> >> For what it's worth, I also have this problem with very slow saving of >> options.el after I've customized something. The weird part is that it >> isn't always slow. >> >> Customize something, Press save->very slow save, and 100% CPU. Press >> C-g. Press save again->fast save. >> Chris> You might want to check the size of your customization file after typing Chris> C-g. That same thing has happened to me, and it turned out that my Chris> customization file shrunk by a significant percentage. YMMV. Yes, I found out later that it was actually corrupted with several partial versions of my faces. Fortunately, I didn't lose my customizations because I had other xemacs processes running. But still, it doesn't always use up 100% CPU. I don't know why. Ray

1 participants
0 comments

Re: font-lock-after-change function unbearably slow; Ben change? 23 years, 11 months

Chris Holt

> > For what it's worth, I also have this problem with very slow saving of > options.el after I've customized something. The weird part is that it > isn't always slow. > > Customize something, Press save->very slow save, and 100% CPU. Press > C-g. Press save again->fast save. > You might want to check the size of your customization file after typing C-g. That same thing has happened to me, and it turned out that my customization file shrunk by a significant percentage. YMMV. Chris

1 participants
0 comments

Plea for help - why are face specs causing faces.el to kill xemacs? 23 years, 11 months

William M. Perry

So, if I try to put GTK resource specs in faces.el like so: (set-face-background 'secondary-selection '(((x default color) . "paleturquoise") ((x default color) . "green") ((x default grayscale) . "gray53") ((gtk default color) . "paleturquoise") ((gtk default color) . "green") ((gtk default grayscale) . "gray53") ((mswindows default color) . "paleturquoise") ((mswindows default color) . "green") ((mswindows default grayscale) . "gray53")) 'global) XEmacs compiled for X or TTY fails to dump, citing the error below. It works fine if the code is built with GTK support, or if I comment out the (gtk default color) specs in the above list. Any clues? This would be one of those !＠#%!＠ we can't put GTK in type of bugs. -Bill P. Loading /usr/local/src/gtk-xemacs-21.2/i686-pc-linux/debug/tty/mule/nounion/lisp /faces.elc...*** Error in XEmacs initialization (error "Invalid color instantiator" global) *** Backtrace really-early-error-handler((error "Invalid color instantiator" global)) check-valid-instantiator(global color) # bind (result noerror specifier-type spec) canonicalize-spec(global color nil) # bind (rest result) byte-code("..." [specifier-type res2 noerror spec-list result rest nil throw c ann-spec-list t signal error "Invalid list format" canonicalize-spec] 5) # (catch cann-spec-list ...) # bind (result noerror specifier-type spec-list) canonicalize-spec-list((global ((x default color) . "paleturquoise") ((x defau lt color) . "green") ((x default grayscale) . "gray53") ((gtk default color) . " paleturquoise") ((gtk default color) . "green") ((gtk default grayscale) . "gray 53") ((mswindows default color) . "paleturquoise") ((mswindows default color) . "green") ((mswindows default grayscale) . "gray53")) color) # bind (is-valid nval how-to-add tag-set locale value specifier) set-specifier(#<color-specifier global=<unspecified> fallback=#<color-specifie r global=<unspecified> fallback=(...) 0x186> 0x79a> (((x default color) . "palet urquoise") ((x default color) . "green") ((x default grayscale) . "gray53") ((gt k default color) . "paleturquoise") ((gtk default color) . "green") ((gtk defaul t grayscale) . "gray53") ((mswindows default color) . "paleturquoise") ((mswindo ws default color) . "green") ((mswindows default grayscale) . "gray53")) global nil nil) # bind (how-to-add tag-set locale value property face) set-face-property(secondary-selection background (((x default color) . "paletu rquoise") ((x default color) . "green") ((x default grayscale) . "gray53") ((gtk default color) . "paleturquoise") ((gtk default color) . "green") ((gtk default grayscale) . "gray53") ((mswindows default color) . "paleturquoise") ((mswindow s default color) . "green") ((mswindows default grayscale) . "gray53")) global n il nil) # bind (how-to-add tag-set locale color face) set-face-background(secondary-selection (((x default color) . "paleturquoise") ((x default color) . "green") ((x default grayscale) . "gray53") ((gtk default color) . "paleturquoise") ((gtk default color) . "green") ((gtk default grayscal

2 participants
1 comments

Re: Building in a different directory? 23 years, 11 months

Raymond Toy

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "Ray" == Raymond Toy <toy(a)rtp.ericsson.se> writes: Ray> I wanted to build xemacs b43 in a different directory to test out a Ray> lesstif version. Ray> I created a lesstif directory inside of xemacs-21.2.43. cd to that Ray> directory and "configure --srcdir=.. <my other favorite options> ". Configure works, but while running make, gcc fails to Ray> compile lwlib.c because it can't find s/sol2.h and m/sparc.h. Martin> Do you really have ".." on your PATH? No, I don't, actually Martin> Does "../configure <my other favorite options>" work? Yes. Ray> This used to work in b40 or so, I think. Martin> Some software projects warn against making $builddir a subdir of Martin> $srcdir. Of course, maintainers generally build with srcdir and Martin> builddir completely separate. Just tried that out now and it works. This is good enough for me. Curiously, it did used to work a few betas ago, exactly as I said above. Oh, well. Thanks, Ray

1 participants
0 comments

ps-print.el fix? 23 years, 11 months

Joel W. Reed

i'm using xemacs 21.2.43. in my .xemacs/init.el i have the following... (defun truncate() (interactive)(setq truncate-lines t)) which seems to collide with the following code from ps-print.el... (defun ps-find-wrappoint (from to char-width) (let ((avail (truncate (/ ps-width-remaining char-width))) (todo (- to from))) (if (< todo avail) (cons to (* todo char-width)) (cons (+ from avail) ps-width-remaining)))) could the "avail (truncate" line in ps-print.el be improved by calling it "avail (sys-truncate" or some such other "system namespace" prefix? or is there some way for my init.el to be improved to not collide. please cc me as i'm not subscribed to this list. thanks, jr -- ------------------------------------------------------------------------ Joel W. Reed 412-257-3881 --------------All the simple programs have been written.----------------

2 participants
1 comments

Building in a different directory? 23 years, 11 months

Raymond Toy

I wanted to build xemacs b43 in a different directory to test out a lesstif version. I created a lesstif directory inside of xemacs-21.2.43. cd to that directory and "configure --srcdir=.. <my other favorite options>". Configure works, but while running make, gcc fails to compile lwlib.c because it can't find s/sol2.h and m/sparc.h. This used to work in b40 or so, I think. Ray

2 participants
1 comments

Remote vulnerability in gnuserv/XEmacs 23 years, 11 months

Jan Vroonhof

SUMMARY All currently available versions of gnuserv for unix prior to 3.12 are vulnerable to remote exploit due to a buffer overflow and weak security. Gnuserv is a remote control facility for Emacsen. Gnuserv ships with XEmacs but is also available stand-alone from various sources for use with GNU Emacs. VULNERABILITY An attacker can excute remote commands with the uid of the user that is running gnuserv. DISCOVERER AND ACKNOWLEDGEMENTS This problem was discovered by Klaus Frank <klausf(a)i3.informatik.rwth-aachen.de>. Klaus provided a fix as well. Many thanks to Klaus for bringing this to attention of the XEmacs and gnuserv maintainers. I also with to thank Vince Shelton and Martin Schwenke for putting fixed releases of XEmacs and gnuserv on the net quickly. DETAIL gnuserv/gnuclient is a pair of utility programs used to sent commands to an already running Emacs process. gnuserv is the helper binary used by the running Emacs to listen for commands. It must be started explicitly using the gnuserv-start command.[1] gnuserv can use several different communication mechanisms, one of them being a tcp port. This can be switched off at compile time, but defaults to on. If enabled gnuserv binds to a user specified TCP port, with the default being (21490 + uid). Note that (if enabled) gnuserv _always_ listens for TCP connections, even if one of the other mechanisms is normally used by the user. Connections on the gnuserv port are authenticated either against a list of trusted hosts or using a MIT-MAGIC-COOKIE based system. (MIT-MAGIC_COOKIE authentication can be switched of, but again is the default.) The problem lies in the fact that the gnuserv program trusts the remote sides specification for the lenght of the cookie without any sanity checking. This allows the attacker to 1. Overflow the buffer used to hold a copy of the cookie. 2. Force the comparison of the cookies to be restricted to a prefix of a length chosen by him, e.g. 1 byte, making bruteforcing the authentication trivial. Both problems are sufficient to give any attacker easy access to running arbitrary commands under the uid of the user running gnuserv. VULNERABLE VERSIONS Unfortunately gnuserv has rather a complicated history: gnuserv was origionally written by Andy Norman (ange). The problematic Xauth based authentication was later added by somebody else. As ange effectively stopped maintaining his version (gnuserv-2.1alpha.tar.gz) various people have put up their own modified copies. That includes among others the version shipped with XEmacs and fgnuserv by Noah Friedman, which is an easier to compile stand-alone version. After a recent rewrite we made the XEmacs version the official verion[2], and bumped the version number to the 3.x range. Martin Schwenke has made a backport of this version for use with Emacs using fgnuserv's build mecahnism. All of the above versions should be assumbed vulnerable, including those shipped with XEmacs 21.1.x for x < 14. As a test run strings gnuserv | grep "gnuserv version" If this gives either nothing or a version below 3.12, then you are vulnerable. NOT VULNERABLE There is a seperate fork for gnuserv on windows for use with NTEmacs. This is not vulnerable as it uses a completely different communication channel. This is, however, unconfirmed. FIXED VERSION A fix by Klaus Frank is in gnuserv 3.12. If you are using XEmacs we suggest upgrading to XEmacs 21.1.14 that contains this version (or 21.2.35 if you are running betas). This version can be had from http://www.xemacs.org/Releases/21.1.14.html or mirrors. If you are using a standalone gnuserv with GNU Emacs on unix we suggest getting Martin Schwenkes fixed version from http://www.linuxcare.com.au/people/martins/hacks/emacs/src/gnuserv-3.12.1... REFERENCES This is the vulnerability indicated in Mandrake Advisory MDKSA-2001:019 Jan Vroonhof <jan(a)xemacs.org> Gnuserv feel-responsible-for-person Footnotes: [1] However I have seen many icons for XEmacs in UI's start "xemacs -f gnuserv" so it is not always obvious to the user he is running gnuserv. [2] With permission form Andy Norman

2 participants
1 comments

animated gifs in VM mbox consume cpu even after deleting or switching msg 23 years, 11 months

Tony Bennett

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta38) "Peisino,Ak(B" [Lucid] (i686-pc-linux) of Tue Jan 9 2001 on uh-oh configured using `configure --with-ldap --with-gcc --error-checking=none --debug=no '--cflags=-g -O3 -Wall -Wno-switch -march=i686'' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Tony E. Bennett <tbennett(a)nvidia.com> wrote: > A coworker includes an animated gif as signature. I made mistake of > clicking on it. After getting over being underwhelmed the 25% hit > on my cpu was annoying. > > Deleting the msg did not help. Moving to new msg did not help. vm-quit > did not help. Finally I just exited XEmacs. > > Is there an easier way to recover here? > Where is this time going? > > vm-version 6.89 kyle> I assume you're using one of the XEmacs betas, because none of kyle> the stable releases support animated GIFs as far as I know. VM kyle> caches glyphs so that images are displayed faster if you reselect kyle> a message. I'm guessing that image instances that aren't being kyle> displayed are still being processed behind the scenes somehow. I kyle> think you should report this to the XEmacs developers. kyle> As to how you can recover without exiting XEmacs, I don't know kyle> how. Try quitting VM and then running M-x garbage-collect . Is this a known bug? Should vm not cache animations? --tony

2 participants
1 comments

b43 still drops core with "gnuclient -nw" 23 years, 11 months

Karl Kleinpaste

Linux RH6.2, 2.2.16. Assorted failures of core dumps with gnuclient -nw. It invariably collapses after a few keystrokes in the tty window. #0 0x4033dd21 in __kill () from /lib/libc.so.6 #1 0x80b0d0e in fatal_error_signal (sig=6) at emacs.c:535 #2 0x4033dc48 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #3 0x4033f0b8 in abort () at ../sysdeps/generic/abort.c:88 #4 0x80b0ba8 in assert_failed (file=0x81bd118 "alloc.c", line=1965, expr=0x81bd120 "old_s_chars->string == s") at emacs.c:3214 #5 0x80858b3 in resize_string (s=0x8836814, pos=-1, delta=-55) at alloc.c:1965 #6 0x8153962 in generate_formatted_string_db (format_str=147513236, result_str=142829588, w=0x8a960c8, dl=0x8c47110, db=0x8a72118, findex=1, min_pixpos=0, max_pixpos=204, type=1) at redisplay.c:3542 #7 0x8153dfc in generate_modeline (w=0x8a960c8, dl=0x8c47110, type=1) at redisplay.c:3667 #8 0x8154aad in ensure_modeline_generated (w=0x8a960c8, type=1) at redisplay.c:4211 #9 0x8155dc6 in regenerate_window (w=0x8a960c8, start_pos=1, point=18, type=1) at redisplay.c:5116 #10 0x81574b6 in redisplay_window (window=145318088, skip_selected=0) at redisplay.c:6105 #11 0x8157852 in redisplay_frame (f=0x89d9548, preemption_check=0) at redisplay.c:6393 #12 0x81579dc in redisplay_device (d=0x8dc0cb0, automatic=1) at redisplay.c:6467 #13 0x8157c08 in redisplay_without_hooks () at redisplay.c:6556 #14 0x815c680 in redisplay () at redisplay.c:6613 #15 0x80ec1fc in Fnext_event (event=140524776, prompt=136505236) at event-stream.c:2177 #16 0x8099aab in Fcommand_loop_1 () at cmdloop.c:574 #17 0x8099cce in command_loop_1 (dummy=136505236) at cmdloop.c:494 #18 0x80b81cb in condition_case_1 (handlers=136505332, bfun=0x8099cb8 <command_loop_1>, barg=136505236, hfun=0x8099600 <cmd_error>, harg=136505236) at eval.c:1651 #19 0x8099dac in command_loop_2 (dummy=136505236) at cmdloop.c:256 #20 0x80b80af in internal_catch (tag=136581596, func=0x8099d74 <command_loop_2>, arg=136505236, threw=0x0) at eval.c:1317 #21 0x809983c in initial_command_loop (load_me=136505236) at cmdloop.c:305 #22 0x80af382 in xemacs_21_2_b43_i686_pc_linux () at emacs.c:2253 #23 0x80b0ef6 in main () at emacs.c:2682 #24 0x403379cb in __libc_start_main (main=0x80b0df8 <main>, argc=5, argv=0xbffff694, init=0x8081418 <_init>, fini=0x81bcbe0 <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff68c) at ../sysdeps/generic/libc-start.c:92 #0 0x4033dd21 in __kill () from /lib/libc.so.6 #1 0x80b0d0e in fatal_error_signal (sig=6) at emacs.c:535 #2 0x4033dc48 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #3 0x4033f0b8 in abort () at ../sysdeps/generic/abort.c:88 #4 0x80b0ba8 in assert_failed (file=0x81bd118 "alloc.c", line=1965, expr=0x81bd120 "old_s_chars->string == s") at emacs.c:3214 #5 0x80858b3 in resize_string (s=0x86f6814, pos=-1, delta=-34) at alloc.c:1965 #6 0x8153962 in generate_formatted_string_db (format_str=144126028, result_str=141518868, w=0x878e858, dl=0x87b58b8, db=0x87cbf28, findex=1, min_pixpos=0, max_pixpos=83, type=1) at redisplay.c:3542 #7 0x8153dfc in generate_modeline (w=0x878e858, dl=0x87b58b8, type=1) at redisplay.c:3667 #8 0x8154aad in ensure_modeline_generated (w=0x878e858, type=1) at redisplay.c:4211 #9 0x8155dc6 in regenerate_window (w=0x878e858, start_pos=1, point=207, type=1) at redisplay.c:5116 #10 0x81574b6 in redisplay_window (window=142141528, skip_selected=1) at redisplay.c:6105 #11 0x815cbfa in redisplay_windows (window=142141528, skip_selected=1) at redisplay.c:6225 #12 0x8156d71 in redisplay_window (window=146695216, skip_selected=1) at redisplay.c:5855 #13 0x815786b in redisplay_frame (f=0x878e6f8, preemption_check=0) at redisplay.c:6225 #14 0x81579dc in redisplay_device (d=0x8786c18, automatic=1) at redisplay.c:6467 #15 0x8157c08 in redisplay_without_hooks () at redisplay.c:6556 #16 0x815c680 in redisplay () at redisplay.c:6613 #17 0x80ed26c in Fsit_for (seconds=1, nodisplay=136505236) at event-stream.c:2803 #18 0x80b4400 in Ffuncall (nargs=2, args=0xbfffed70) at eval.c:3549 #19 0x808faee in execute_optimized_program ( program=0x8565ce0 "Æ \211\035＠\r＠Ç¥Ç_ZÈ_\eÉ\r!\034ÊËÌ\217\0364\0165®\013ÍÎ!®\006\0166Ï P\211\0361;I\n«\f\rA＠\013\\\nZÐV;Æ \031Ñ\0161!Æ \211\025＠\r＠Ç¥Ç_ZÈ_\023\rA＠\013\\\tA＠\t＠\t＠Ç¥Ç_ZÈ_\\ZÒV«\t\rA＠\013\\\022ª\003Ê\022)\0367\fÓÔO\0362Õ\0162!\030Ö\bÓ\\×¦T!\0368\b×Y«\004Øª\002Ù\0369\fÚÛO\036:\fÜÝO\036;Þ\r!A＠\036<\fßÇO\036=\fÒàO\036>\fáâO\0363ã\0163ä\"A\036?\fåæO"..., stack_depth=7, constants_data=0x8607970) at bytecode.c:746 #20 0x808f7b4 in funcall_compiled_function (fun=137359924, nargs=0, args=0xbfffee74) at bytecode.c:515 #21 0x80b444f in Ffuncall (nargs=1, args=0xbfffee70) at eval.c:3563 #22 0x808faee in execute_optimized_program ( program=0xbfffeec0 "Æ \eÇ\216\f\035È\211\032\031È\211\030\036\rÈ\211\036\016\034È\211\036\017\036\020É\r!«\fÊË\r!Ì\r!\"\210ª\006Ë\r! \210.\013È\207ð?6\blðÿ¿¬ç\"\b\003", stack_depth=5, constants_data=0x84395d0) at bytecode.c:746 #23 0x8091bfd in Fbyte_code (instructions=138645044, constants=138646976, stack_depth=11) at bytecode.c:2403 #24 0x80b3adb in Feval (form=138566372) at eval.c:3331 #25 0x80b1f90 in condition_case_3 (bodyform=138566372, var=138628420, handlers=138566072) at eval.c:1651 #26 0x8090413 in execute_rare_opcode (stack_ptr=0xbffff190, program_ptr=0x869923d "\210)\013A\211\023¬\217\016\036\211\023«\016\fÔ\013＠!^\024\013A\211\023¬ôÚÛ!\211\036\037«\fÜ\016\037!«\006\212Ý \210))\f.\a\207", opcode=Bcondition_case) at bytecode.c:1271 #27 0x808f93b in execute_optimized_program ( program=0x8699188 "Æ\016\036!ÇÈÇ\211\211É\036 \030\032\031\034\035\eÈ\024ÊË!«\021\016\013:«\f\016\013\022ÌÍ \n\"\021ª ÊÎ!«\027\016\016:«\022\016\016＠\016\016AÏE\022ÌÍ \n\"\021ª\005Ð\022Ï\021\013«s\013＠\025Ñ\r!«\aÒ\r!\020ª\rÓ\rÏÔ\r!\016!Z]\"\210Ñ\r!«\020Ì\b\n\"ÏV¬\017\tÔ\r!Wª\006Ô\r!ÏV«%Ñ\r!«\030\tÔ\r!W«\n\fÔ\r!\tZ^ª\r\fÔ\r!^ª\006\fÔ\r!^\024ª\024Ñ\r!«\aÕ\rÍ \"\210Ö\216×ØÙ\217\210)\013A\211\023¬\217\016\036\211\023«\016\fÔ\013＠!"..., stack_depth=8, constants_data=0x8439680) at bytecode.c:656 #28 0x808f7b4 in funcall_compiled_function (fun=138651372, nargs=1, args=0xbffff290) at bytecode.c:515 #29 0x80b444f in Ffuncall (nargs=2, args=0xbffff28c) at eval.c:3563 #30 0x808faee in execute_optimized_program ( program=0x86990e8 "\013?&Æ\211\036\017\eÇ \034È\f\n\"\031É\035\f\022Ê\t!\025Ë\b!\210\r\026\020Ì\rÍÉÎ$\211\020-\207", stack_depth=6, constants_data=0x8441540) at bytecode.c:746 #31 0x808f7b4 in funcall_compiled_function (fun=138651624, nargs=1, args=0xbffff38c) at bytecode.c:515 #32 0x80b444f in Ffuncall (nargs=2, args=0xbffff388) at eval.c:3563 #33 0x80b771c in call1 (fn=138628636, arg0=136505236) at eval.c:4183 #34 0x80ed604 in execute_internal_event (event=140518216) at event-stream.c:3030 #35 0x80eef26 in Fdispatch_event (event=140518216) at event-stream.c:4170 #36 0x8099abd in Fcommand_loop_1 () at cmdloop.c:583 #37 0x8099cce in command_loop_1 (dummy=136505236) at cmdloop.c:494 #38 0x80b81cb in condition_case_1 (handlers=136505332, bfun=0x8099cb8 <command_loop_1>, barg=136505236, hfun=0x8099600 <cmd_error>, harg=136505236) at eval.c:1651 #39 0x8099dac in command_loop_2 (dummy=136505236) at cmdloop.c:256 #40 0x80b80af in internal_catch (tag=136581596, func=0x8099d74 <command_loop_2>, arg=136505236, threw=0x0) at eval.c:1317 #41 0x809983c in initial_command_loop (load_me=136505236) at cmdloop.c:305 #42 0x80af382 in xemacs_21_2_b43_i686_pc_linux () at emacs.c:2253 #43 0x80b0ef6 in main () at emacs.c:2682 #44 0x403379cb in __libc_start_main (main=0x80b0df8 <main>, argc=1, argv=0xbffff6d4, init=0x8081418 <_init>, fini=0x81bcbe0 <_fini>, rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff6cc) at ../sysdeps/generic/libc-start.c:92 uname -a: Linux belladonna.iolitemedia.com 2.2.16-k10021 #1 Mon Oct 2 13:48:01 EDT 2000 i686 unknown ./configure '--with-pop' '--with-mule' '--error-checking=none' '--debug=no' XEmacs 21.2-b43 "Terspichore" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /usr/src/Packages/xemacs/xemacs-21.2.43 Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: /usr/bin/gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for GNU DBM. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: pgsql/libpq-fe.h Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. Mail: Compiling in support for POP mail retrieval. Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules.

2 participants
3 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 February 2001