Andy Piper <andy(a)xemacs.org&gt; wrote: The endless tab redisplay problem is still present, as of a cvs update of 4PM PST (0000GMT?) Sept. 17. -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

A while back (Sat, 18 Sep 1999), Andy Piper <andy(a)xemacs.org&gt; wrote: OK, I've finally gotten a simple test case, which I've managed to reproduce on the latest XEmacs 21.2, obtained via cvs update around 3:50PM PST (2300GMT), September 24. To reproduce: * Use these X resources (I don't know if these are really necessary to reproduce the bug, but I'm listing them anyway): Emacs*EmacsFrame.default.attributeBackground: black Emacs*EmacsFrame.default.attributeForeground: white Emacs*EmacsFrame.geometry: 177x55+6+20 Emacs*cursorColor: green Emacs.default.attributeFont: -*-Fixed-Medium-O-*-*-*-130-*-*-*-*-*-* * cd to XEmacs's src subdirectory, and run: ./xemacs -q -vanilla * Use M-x load-file to load the attached "foo.el" file. All this file does is set the default face. However, if this file is not loaded, XEmacs works fine. * Type: C-x 3 # split window vertically. C-x o # switch to the right-hand window C-x C-f alloc.c # edit alloc.c C-x o # switch back to left-hand window Once you switch back to the left-hand window, the tab window starts flickering, and never stops. Interestingly, you can still type and execute commands while the flickering is occurring. I've also attached a copy of my "Installation" file. -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

From: Andy Piper <andy(a)xemacs.org&gt; Subject: Subwindow clipping Date: Thu, 16 Sep 1999 17:59:33 +0100 Hi, latest CVS (Sep, 18) still exhibits the tab redrawing bug, with a couple of annoying additions: I consistently get: $ src/xemacs src/xemacs: Symbol `toggleClassRec' has different size in shared object, consider re-linking src/xemacs: Symbol `labelClassRec' has different size in shared object, consider re-linking even right after compiltion (actually I get those even in the temacs run duuring the make process). I often get: 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&#39;. *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/src/xemacs-21/xemacs-21.2/src/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: # (condition-case ... . error) # (catch top-level ...) Segmentation fault (core dumped) $ I dutifully complied and got: $ gdb src/xemacs core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `src/xemacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/Xaw3d/libXaw.so.6...done. Reading symbols from /usr/lib/libtiff.so.3...done. Reading symbols from /usr/lib/libpng.so.2...done. Reading symbols from /usr/lib/libjpeg.so.62...done. Reading symbols from /usr/lib/libz.so.1...done. Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /usr/lib/libgpm.so.1...done. Reading symbols from /lib/libncurses.so.4...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /lib/libnss_compat.so.2...done. Reading symbols from /lib/libnsl.so.1...done. #0 0x402fc0a1 in kill () from /lib/libc.so.6 (gdb) where #0 0x402fc0a1 in kill () from /lib/libc.so.6 #1 0x807fd04 in fatal_error_signal (sig=11) at emacs.c:276 #2 0x402fbfd8 in __restore () from /lib/libc.so.6 #3 0x815672f in x_event_to_emacs_event (x_event=0xbffff4cc, emacs_event=0x86db504) at event-Xt.c:999 #4 0x81584ca in emacs_Xt_event_handler (wid=0x852ec88, closure=0x0, event=0xbffff4cc, continue_to_dispatch=0xbffff413 "\001ðÕL\b&") at event-Xt.c:2475 #5 0x4013706c in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #6 0x401379cd in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6 #7 0x40137c0d in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #8 0x40142527 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #9 0x8157679 in emacs_Xt_next_event (emacs_event=0x86db660) at event-Xt.c:2427 #10 0x80b4d85 in event_stream_next_event (event=0x86db660) at event-stream.c:565 #11 0x80b5f4c in next_event_internal (target_event=141407840, allow_queued=1) at event-stream.c:2020 #12 0x80b6317 in Fnext_event (event=141407840, prompt=136486996) at event-stream.c:2237 #13 0x8067729 in Fcommand_loop_1 () at cmdloop.c:569 #14 0x806799d in command_loop_1 (dummy=136486996) at cmdloop.c:493 #15 0x80875ae in condition_case_1 (handlers=136487092, bfun=0x8067984 <command_loop_1>, barg=136486996, hfun=0x8067a0c <cmd_error>, harg=136486996) at eval.c:1646 #16 0x8067aff in command_loop_2 (dummy=136486996) at cmdloop.c:255 #17 0x808747c in internal_catch (tag=136561188, func=0x8067ac0 <command_loop_2>, arg=136486996, threw=0x0) at eval.c:1321 #18 0x806743e in initial_command_loop (load_me=136486996) at cmdloop.c:304 #19 0x807e314 in sort_args (argc=1, argv=0xbffffb34) at emacs.c:1762 #20 0x807ff10 in voodoo_free_hook (mem=0x1) at emacs.c:2187 #21 0x402f6222 in __libc_start_main () from /lib/libc.so.6 (gdb) quit $ Hope it helps. Thanks Mauro

From: Andy Piper <andy(a)xemacs.org&gt; Subject: Re: Subwindow clipping Date: Sun, 19 Sep 1999 14:13:01 +0100 I get it consistently using mew (I compile with mule because mew wants it and for no other reason). I include also my ~/.emacs in case something in it triggers the bug (I change the default cheracher size). While We are on the subject: I now notice that using 21.1.6 mew prints message headers in bold, but with the default font and size. Under xemacs 21.2 mew displays the headers in a different font (sans-serif) and size. Other data point: when I switch windows in mew (C-x, o) the tabs (not the labels in them) change size. The recipe to reproduce is: - open mew - get the inbox - go to a message and hit space to display it. - switch point to the message window (C-x, o). - move the mouse pointer over the tabs. - BOOOM Sorry I cannot be more precise, but I'm in a real hurry (my plane leaves in a couple of hours) and I will be unreachable until Thursday evening. Correct. I will search for that. Thanks. Best Regards Mauro

Glynn> Mauro Condarelli wrote: Glynn> This indicates that the Xaw headers used for compilation Glynn> don't match the libXaw.so which is being used at run-time Glynn> (e.g. compiling with vanilla Xaw headers but using the Glynn> libXaw.so from Xaw3d). This is still happening to me ... I've confirmed (using CPPFLAGS=-H) that I'm getting the right headers ... ldd src/xemacs tells me I'm getting the right library ... but bogosity rules!! Aha! Debian (unstable == potato, current as of a couple days ago) supplies both the standard libXaw.so and a libXaw3d.so, by those names, in /usr/X11R6/lib. This is unlikely to go away since there are several programs that don't seem to coexist with Athena 3D for some reason. `ln -sf libXaw3d.so.6.1 libXaw.so' and bingo! no errors. But I don't think I want to do this permanently. Or do I? (Advice, please.) If not, Would it be reasonable for ./configure (once it has decided to use Xaw3d) to test for the existence of libXaw3d.so (and maybe libXaw3d.a, but maybe not) and do `-lXaw3d' instead of `-lXaw' in that case? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."

SJT> Debian (unstable == potato, current as of a couple days ago) supplies SJT> both the standard libXaw.so and a libXaw3d.so, by those names, in SJT> /usr/X11R6/lib. This is unlikely to go away since there are several SJT> programs that don't seem to coexist with Athena 3D for some reason. SJT> `ln -sf libXaw3d.so.6.1 libXaw.so' and bingo! no errors. But I don't SJT> think I want to do this permanently. SJT> Or do I? (Advice, please.) i doubt it. at least when i tried running this way several years ago, i would eventually always find some program that would crap out on the Xaw3d libs. So I've always kept them separate. SJT> If not, Would it be reasonable for ./configure (once it has decided to SJT> use Xaw3d) to test for the existence of libXaw3d.so (and maybe SJT> libXaw3d.a, but maybe not) and do `-lXaw3d' instead of `-lXaw' in that SJT> case? Ideally it would be nice if there was a way to specify this in configure. Until then, I have this in my build script for the xaw3d case: if [ $1 = "xaw3d" ]; then mv src/Makefile src/Makefile.orig mv src/GNUmakefile src/GNUmakefile.orig sed -e s/-lXaw/-lXaw3d/ src/Makefile.orig > src/Makefile sed -e s/-lXaw/-lXaw3d/ src/GNUmakefile.orig > src/GNUmakefile fi

SJT> `ln -sf libXaw3d.so.6.1 libXaw.so' and bingo! no errors. But I SJT> don't think I want to do this permanently. SJT> Or do I? (Advice, please.) Maybe. Here's how dynamic linking and shared objects are supposed to work: Dynamic ELF applications have a .dynamic section which has a number of fields containing information about the dynamic requirements of the app. In particular, for this discussion, there is one or more NEEDED members which describe the shared objects that the binary needs to run (such as libc.so.1). You'll note that these are versioned names. On Solaris, you can look at the .dynamic section with dump -Lv <binary>. Now, when shared objects are created, ld takes its -h "name" argument (or the -o "name" in -h's absence) and records that name into the resulting object. So, libc is built with a "-h libc.so.1". This name appears in the SONAME member of the .dynamic section. When creating a dynamic executable, the link editor (ld, usually invoked under the covers by the compiler) takes arguments in the form -lc and translates them to "libc.so" and looks in each of the directories defined by "-L" options or $LD_LIBRARY_PATH or any default path such as /usr/lib. Note: ld will NOT find /usr/lib/libc.so.1 So, in the case of a simple app linking with libc, ld simply opens /usr/lib/libc.so and as part of its work, it takes the SONAME from libc.so and writes it out again as a NEEDED in the app. ld doesn't know or care that libc.so is a symlink... Now, at some point, somebody decides that libc needs upgrading in a manner that renders it incompatible with libc.so.1. Thus libc.so.2 is born. It is further decided that all NEW applications should link to this, so the symlink libc.so is revectored to libc.so.2. libc.so.1 will continue to exist and be available to applications that have been linked against it. Pretty simple really. But there are many ways to screw this up and I suspect that in your installation that is exactly what has happened. Hope I've helped you decide on the correct course...