Re: Emacs tramp mode doesn't work with CURRENT
On 1/28/20 8:57 AM, John F Carr wrote: > I use emacs tramp mode, which opens an ssh connection to a remote machine for > file access. It works to Linux and FreeBSD 12.1, but not to CURRENT. There > has been a change in the way characters are echoed by the shell, with 12.1 > treating a consecutive run of backspace as an atomic unit and CURRENT > processing them one at a time. This is not necessarily a bug, but it is a > nuisance and independently it is suboptimal. I have the same breakage with an amd64 laptop running HEAD (and using tramp-mode from emacs on a 12.x host) Have you been able to bisect it at all? I think libedit is probably a good candidate as well. What I see is that tramp-mode just hangs until I kill the ssh session it is using, and then I see the same output you had below in the debug window showing the extraneous newlines. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Emacs tramp mode doesn't work with CURRENT
I use emacs tramp mode, which opens an ssh connection to a remote machine for file access. It works to Linux and FreeBSD 12.1, but not to CURRENT. There has been a change in the way characters are echoed by the shell, with 12.1 treating a consecutive run of backspace as an atomic unit and CURRENT processing them one at a time. This is not necessarily a bug, but it is a nuisance and independently it is suboptimal. I would like to blame libedit, which changed since 12.1. I didn't see any changes in pty code and the problem happens with at least two different shells. It could also be caused by a change to sshd or something I haven't through of. Here is a longer explanation. Emacs tramp mode opens an ssh connection to a remote machine. It doesn't want to see input echoed back so it runs stty -inlcr -onlcr -echo kill '^U' erase '^H' This doesn't do anything useful if a shell is running in line editing mode (raw) instead of using the tty (cooked). So tramp falls back to a hack to detect echoed input. It sends "_echo" followed by a string of backspace characters. "_echo" is unlikely to appear in program output. Here is the next command after the initial stty: _echo^H^H^H^H^Hstty icanon erase ^H cols 32767_echo^H^H^H^H^H The groups of 5 ^H represent 5 backspace characters and the lone ^H in the middle is a two character sequence for stty. The terminal output from a 12.1 system is _echo^H ^H^H ^H^H ^H^H ^H^H ^Hstty icanon erase ^H cols 32767_echo^H ^H^H ^H^H ^H^H ^H^H ^H #$ where again the middle ^H is a two character sequence and the others are backspace characters. There is a carriage return between the two lines. "#$ " is the shell prompt set by tramp. The terminal output from a CURRENT system is _echo #$ _ech ^H #$ _ec ^H #$ _e ^H #$ _ ^H #$ ^Hstty icanon erase ^H cols 32767_echo #$ stty icanon erase ^H cols 32767_ech ^H #$ stty icanon erase ^H cols 32767_ec ^H #$ stty icanon erase ^H cols 32767_e ^H #$ stty icanon erase ^H cols 32767_ ^H #$ stty icanon erase ^H cols 32767 ^H #$ with carriage returns between lines. This does not make sense to emacs. I tried both /bin/sh and /bin/csh as shells and tramp didn't work with either. I put set +V and set +E in my .profile thinking that would turn off line editing but there was no change. Probably the shell still takes raw input. A possible complicating factor is the CURRENT machines are both 64 bit ARM and the 12.1 machine is amd64. One has unsigned characters, the other signed. Shouldn't matter, but I haven't tried 12.1 on ARM so I can't swear it works. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Emacs and LLD
On Mon, Nov 20, 2017 at 2:39 PM, Ed Maste <ema...@freebsd.org> wrote: > On 3 November 2017 at 11:29, Tobias Kortkamp <to...@freebsd.org> wrote: > > > > My src.conf has WITH_LLD_IS_LD=yes and reading > > https://bugs.freebsd.org/214864 leads me to believe that it's somehow > > responsible for the problems I have with Emacs. > > Yes, the emacs build does some rather unusual things and it's perhaps > not surprising that it's one of the ports that's giving grief with > lld. > > The exp-run shows the same error you experienced: > > ./temacs --batch --load loadup bootstrap > Fatal error 'Can't allocate initial thread' at line 337 in file > /poudriere/jails/headamd64PR214864/usr/src/lib/libthr/thread/thr_init.c > (errno = 12) > gmake[2]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped) > > I don't yet have any insight into the failure, and hope that someone > with knowledge of the emacs build process and emacs internals can take > a look. > Is temacs still an 'undumped' core dump[*]? Maybe the undumping code isn't playing well with lld's different behavior than ld? Warner [*] For speed, emacs use to compile all its lisp, load it into a memory arena, then take a core dump. The core dump was cleaned up so it could be used as an executable with the now-preloaded lisp code in place. It was a standard thing on 'big iron' that EMACS came from, but always a bit of an 'odd duck' as far as fitting into how Unix works. There used to be knobs to do it differently for things like VMS that simply couldn't easily cope. Maybe one of those needs to be tweaked? It's a tiny bit slower, but with the speed of today's hardware (and most hardware made since ~2000), the optimization likely saves time below the human threshold to detect... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Emacs and LLD
On 3 November 2017 at 11:29, Tobias Kortkamp <to...@freebsd.org> wrote: > > My src.conf has WITH_LLD_IS_LD=yes and reading > https://bugs.freebsd.org/214864 leads me to believe that it's somehow > responsible for the problems I have with Emacs. Yes, the emacs build does some rather unusual things and it's perhaps not surprising that it's one of the ports that's giving grief with lld. The exp-run shows the same error you experienced: ./temacs --batch --load loadup bootstrap Fatal error 'Can't allocate initial thread' at line 337 in file /poudriere/jails/headamd64PR214864/usr/src/lib/libthr/thread/thr_init.c (errno = 12) gmake[2]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped) I don't yet have any insight into the failure, and hope that someone with knowledge of the emacs build process and emacs internals can take a look. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Emacs and LLD
On Fri, Nov 3, 2017, at 16:59, Hans Petter Selasky wrote: > On 11/03/17 16:29, Tobias Kortkamp wrote: > > Hi, > > > > I cannot build editors/emacs-nox11 (or any other Emacs port) on FreeBSD > > 12 anymore for several months now. The build aborts with: > > > > ./temacs --batch --load loadup bootstrap > > Fatal error 'Can't allocate initial thread' at line 337 in file > > /usr/src/lib/libthr/thread/thr_init.c (errno = 12) > > gmake[3]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped) > > > > I'm currently running base r324724. Emacs builds fine on the cluster, > > so I thought installing the binary package from pkg.FreeBSD.org would be > > an OK solution, but it immediately crashes too. > > > > My src.conf has WITH_LLD_IS_LD=yes and reading > > https://bugs.freebsd.org/214864 leads me to believe that it's somehow > > responsible for the problems I have with Emacs. > > > > Setting LLD_UNSAFE=yes in the port does not solve the problem. If I > > manually link temacs statically the build can continue, however the > > emacs binary temacs dumps is not usable and immediately crashes. > > > > I can "solve" the problem (in the sense that I can run Emacs again > > outside of a chroot/jail) by extracting /lib/libc.so.7 from a recent > > snapshot (I tried with 20171012-r324542 and the current base.txz > > snapshot) not built with LLD and running it with > > > > LD_PRELOAD="/path/to/libc.so.7" emacs > > > > It'll do for now, but this just doesn't feel right... > > > > Thanks in advance for any insight you can provide! > > > > Backtrace from temacs: > > > > * thread #1, name = 'temacs', stop reason = signal SIGABRT > >* frame #0: 0x000800e089aa libc.so.7`__sys_thr_kill at > >thr_kill.S:3 > > frame #1: 0x000800e08974 libc.so.7`__raise(s=6) at raise.c:52 > > frame #2: 0x000800e088e9 libc.so.7`abort at abort.c:65 > > frame #3: 0x000800c8c88a > > libthr.so.3`_thread_exitf(fname=, lineno=, > > fmt=) at thr_exit.c:193 > > frame #4: 0x000800c8a02e > > libthr.so.3`_libpthread_init(curthread=0x) at > > thr_init.c:337 > > frame #5: 0x000800c8d4b2 libthr.so.3 > > frame #6: 0x000800c8d4d6 libthr.so.3`_init + 14 > > frame #7: 0x0008007b0058 > > ld-elf.so.1`objlist_call_init(list=, > > lockstate=) at rtld.c:2643 > > frame #8: 0x0008007af3eb > > ld-elf.so.1`_rtld(sp=0x7fffdf08, > > exit_proc=0x7fffdeb0, objp=0x7fffdeb8) at rtld.c:759 > > frame #9: 0x0008007ad019 ld-elf.so.1`.rtld_start at > > rtld_start.S:39 > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > Hi, > > security.bsd.stack_guard_page: 1 > > Does setting the above sysctl to zero make any difference? No, unfortunately not. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Emacs and LLD
On 11/03/17 16:29, Tobias Kortkamp wrote: Hi, I cannot build editors/emacs-nox11 (or any other Emacs port) on FreeBSD 12 anymore for several months now. The build aborts with: ./temacs --batch --load loadup bootstrap Fatal error 'Can't allocate initial thread' at line 337 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) gmake[3]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped) I'm currently running base r324724. Emacs builds fine on the cluster, so I thought installing the binary package from pkg.FreeBSD.org would be an OK solution, but it immediately crashes too. My src.conf has WITH_LLD_IS_LD=yes and reading https://bugs.freebsd.org/214864 leads me to believe that it's somehow responsible for the problems I have with Emacs. Setting LLD_UNSAFE=yes in the port does not solve the problem. If I manually link temacs statically the build can continue, however the emacs binary temacs dumps is not usable and immediately crashes. I can "solve" the problem (in the sense that I can run Emacs again outside of a chroot/jail) by extracting /lib/libc.so.7 from a recent snapshot (I tried with 20171012-r324542 and the current base.txz snapshot) not built with LLD and running it with LD_PRELOAD="/path/to/libc.so.7" emacs It'll do for now, but this just doesn't feel right... Thanks in advance for any insight you can provide! Backtrace from temacs: * thread #1, name = 'temacs', stop reason = signal SIGABRT * frame #0: 0x000800e089aa libc.so.7`__sys_thr_kill at thr_kill.S:3 frame #1: 0x000800e08974 libc.so.7`__raise(s=6) at raise.c:52 frame #2: 0x000800e088e9 libc.so.7`abort at abort.c:65 frame #3: 0x000800c8c88a libthr.so.3`_thread_exitf(fname=, lineno=, fmt=) at thr_exit.c:193 frame #4: 0x000800c8a02e libthr.so.3`_libpthread_init(curthread=0x) at thr_init.c:337 frame #5: 0x000800c8d4b2 libthr.so.3 frame #6: 0x000800c8d4d6 libthr.so.3`_init + 14 frame #7: 0x0008007b0058 ld-elf.so.1`objlist_call_init(list=, lockstate=) at rtld.c:2643 frame #8: 0x0008007af3eb ld-elf.so.1`_rtld(sp=0x7fffdf08, exit_proc=0x7fffdeb0, objp=0x7fffdeb8) at rtld.c:759 frame #9: 0x0008007ad019 ld-elf.so.1`.rtld_start at rtld_start.S:39 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Hi, security.bsd.stack_guard_page: 1 Does setting the above sysctl to zero make any difference? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Emacs and LLD
Hi, I cannot build editors/emacs-nox11 (or any other Emacs port) on FreeBSD 12 anymore for several months now. The build aborts with: ./temacs --batch --load loadup bootstrap Fatal error 'Can't allocate initial thread' at line 337 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 12) gmake[3]: *** [Makefile:737: bootstrap-emacs] Abort trap (core dumped) I'm currently running base r324724. Emacs builds fine on the cluster, so I thought installing the binary package from pkg.FreeBSD.org would be an OK solution, but it immediately crashes too. My src.conf has WITH_LLD_IS_LD=yes and reading https://bugs.freebsd.org/214864 leads me to believe that it's somehow responsible for the problems I have with Emacs. Setting LLD_UNSAFE=yes in the port does not solve the problem. If I manually link temacs statically the build can continue, however the emacs binary temacs dumps is not usable and immediately crashes. I can "solve" the problem (in the sense that I can run Emacs again outside of a chroot/jail) by extracting /lib/libc.so.7 from a recent snapshot (I tried with 20171012-r324542 and the current base.txz snapshot) not built with LLD and running it with LD_PRELOAD="/path/to/libc.so.7" emacs It'll do for now, but this just doesn't feel right... Thanks in advance for any insight you can provide! Backtrace from temacs: * thread #1, name = 'temacs', stop reason = signal SIGABRT * frame #0: 0x000800e089aa libc.so.7`__sys_thr_kill at thr_kill.S:3 frame #1: 0x000800e08974 libc.so.7`__raise(s=6) at raise.c:52 frame #2: 0x000800e088e9 libc.so.7`abort at abort.c:65 frame #3: 0x000800c8c88a libthr.so.3`_thread_exitf(fname=, lineno=, fmt=) at thr_exit.c:193 frame #4: 0x000800c8a02e libthr.so.3`_libpthread_init(curthread=0x) at thr_init.c:337 frame #5: 0x000800c8d4b2 libthr.so.3 frame #6: 0x000800c8d4d6 libthr.so.3`_init + 14 frame #7: 0x0008007b0058 ld-elf.so.1`objlist_call_init(list=, lockstate=) at rtld.c:2643 frame #8: 0x0008007af3eb ld-elf.so.1`_rtld(sp=0x7fffdf08, exit_proc=0x7fffdeb0, objp=0x7fffdeb8) at rtld.c:759 frame #9: 0x0008007ad019 ld-elf.so.1`.rtld_start at rtld_start.S:39 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstaller / partedit emacs key patch
On 03/31/11 22:39, Daniel O'Connor wrote: On 01/04/2011, at 5:09, Nathan Whitehorn wrote: On 03/29/11 20:50, Daniel O'Connor wrote: Hi, I noticed that the entry widgets in the bsdinstaller label editor don't understand various emacs keys (eg C-a, C-d, C-e). Here's a patch which adds the basics.. Unfortunately dialog doesn't have a key for delete all, delete left or delete right so I couldn't add C-u, C-w or C-k. Note that you can't just call dlg_parse_bindkey(* ^a BEGIN) because dialog modifies the string which crashes (seg fault). I'm happy to put this in, but it would be nice if you could try to get this into upstream dialog to avoid inconsistencies in various parts of the installation. I suspect it would be pretty bikeshed prone :( Is there a dialog mailing list? My google-fu failed and I can't find one. I suppose the alternative is to install a global rc file (ie /etc/dialogrc) with the following contents.. bindkey * ^a BEGIN bindkey * ^d DELETE_RIGHT bindkey * ^e FINAL Here's the website: http://invisible-island.net/dialog/dialog.html The nearest thing to a mailing list is the ncurses one, but I'd suggest just emailing the author. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstaller / partedit emacs key patch
On 03/29/11 20:50, Daniel O'Connor wrote: Hi, I noticed that the entry widgets in the bsdinstaller label editor don't understand various emacs keys (eg C-a, C-d, C-e). Here's a patch which adds the basics.. Unfortunately dialog doesn't have a key for delete all, delete left or delete right so I couldn't add C-u, C-w or C-k. Note that you can't just call dlg_parse_bindkey(* ^a BEGIN) because dialog modifies the string which crashes (seg fault). I'm happy to put this in, but it would be nice if you could try to get this into upstream dialog to avoid inconsistencies in various parts of the installation. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstaller / partedit emacs key patch
On 01/04/2011, at 5:09, Nathan Whitehorn wrote: On 03/29/11 20:50, Daniel O'Connor wrote: Hi, I noticed that the entry widgets in the bsdinstaller label editor don't understand various emacs keys (eg C-a, C-d, C-e). Here's a patch which adds the basics.. Unfortunately dialog doesn't have a key for delete all, delete left or delete right so I couldn't add C-u, C-w or C-k. Note that you can't just call dlg_parse_bindkey(* ^a BEGIN) because dialog modifies the string which crashes (seg fault). I'm happy to put this in, but it would be nice if you could try to get this into upstream dialog to avoid inconsistencies in various parts of the installation. I suspect it would be pretty bikeshed prone :( Is there a dialog mailing list? My google-fu failed and I can't find one. I suppose the alternative is to install a global rc file (ie /etc/dialogrc) with the following contents.. bindkey * ^a BEGIN bindkey * ^d DELETE_RIGHT bindkey * ^e FINAL -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bsdinstaller / partedit emacs key patch
Hi,
I noticed that the entry widgets in the bsdinstaller label editor don't
understand various emacs keys (eg C-a, C-d, C-e).
Here's a patch which adds the basics.. Unfortunately dialog doesn't have a
key for delete all, delete left or delete right so I couldn't add C-u, C-w or
C-k.
Note that you can't just call dlg_parse_bindkey(* ^a BEGIN) because dialog
modifies the string which crashes (seg fault).
--- partedit.c.orig 2011-03-30 01:41:20.0 +
+++ partedit.c 2011-03-30 01:47:06.0 +
@@ -50,6 +50,13 @@
static void get_mount_points(struct partedit_item *items, int nitems);
static int validate_setup(void);
+static char *bindings[] = {
+ * ^a BEGIN,
+ * ^d DELETE_RIGHT,
+ * ^e FINAL,
+ NULL
+};
+
int
main(int argc, const char **argv) {
struct partition_metadata *md;
@@ -58,12 +65,18 @@
struct gmesh mesh;
int i, op, nitems, nscroll;
int error;
+ char tmp[80];
TAILQ_INIT(part_metadata);
init_fstab_metadata();
init_dialog(stdin, stdout);
+
+ for (i = 0; bindings[i] != NULL; i++) {
+ *stpncpy(tmp, bindings[i], sizeof(tmp) - 1) = 0;
+ dlg_parse_bindkey(tmp);
+ }
if (strcmp(basename(argv[0]), sade) != 0)
dialog_vars.backtitle = __DECONST(char *, FreeBSD Installer);
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. It aborts on exit (C-x C-c) after receiving SIGBUS: f...@r500 ~ $gdb emacs GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 amd64-marcel-freebsd... (gdb) run Starting program: /usr/local/bin/emacs [New LWP 100281] [New Thread 1260600 (LWP 100281)] Program received signal SIGBUS, Bus error. [Switching to Thread 1260600 (LWP 100281)] 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 (gdb) where #0 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 #1 0x000803038abb in __pthread_cxa_finalize () from /lib/libthr.so.3 #2 0x0008045bdfa7 in __cxa_finalize () from /lib/libc.so.7 #3 0x0008045682c7 in exit () from /lib/libc.so.7 #4 0x00556817 in Fkill_emacs (arg=Could not find the frame base for Fkill_emacs. ) at emacs.c:2146 #5 0x00600ec0 in Ffuncall (nargs=1, args=0x7fffc880) at eval.c:3024 #6 0x00658d47 in Fbyte_code (bytestr=8602321, vector=8602357, maxdepth=20) at bytecode.c:680 #7 0x006017e6 in funcall_lambda (fun=8602229, nargs=0, arg_vector=0x7fffcdc8) at eval.c:3211 #8 0x006011e0 in Ffuncall (nargs=1, args=0x7fffcdc0) at eval.c:3070 #9 0x00658d47 in Fbyte_code (bytestr=9558105, vector=9558141, maxdepth=20) at bytecode.c:680 #10 0x006017e6 in funcall_lambda (fun=9558029, nargs=1, arg_vector=0x7fffd358) at eval.c:3211 #11 0x006011e0 in Ffuncall (nargs=2, args=0x7fffd350) at eval.c:3070 #12 0x005fb954 in Fcall_interactively (function=11961778, record_flag=11544578, keys=20138021) at callint.c:869 #13 0x00600f36 in Ffuncall (nargs=4, args=0x7fffd760) at eval.c:3030 #14 0x006008fd in call3 (fn=11756290, arg1=11961778, arg2=11544578, arg3=20138021) at eval.c:2850 #15 0x0056b7ac in Fcommand_execute (cmd=11961778, record_flag=11544578, keys=20138021, special=11544674) at keyboard.c:10507 #16 0x0055cc69 in read_char (commandflag=1, nmaps=2, maps=0x7fffdb70, prev_event=11544578, used_mouse_menu=0x7fffded4, end_time=0x0) at keyboard.c:3166 #17 0x0056880e in read_key_sequence (keybuf=0x7fffe280, bufsize=30, prompt=11544578, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9512 #18 0x00558a33 in command_loop_1 () at keyboard.c:1643 #19 0x005fe0aa in internal_condition_case (bfun=0x5586a0 command_loop_1, handlers=11629954, hfun=0x557f90 cmd_error) at eval.c:1490 #20 0x0055836a in command_loop_2 () at keyboard.c:1360 #21 0x005fda2c in internal_catch (tag=11621170, func=0x558350 command_loop_2, arg=11544578) at eval.c:1226 #22 0x00558320 in command_loop () at keyboard.c:1339 #23 0x00557a85 in recursive_edit_1 () at keyboard.c:954 #24 0x00557c45 in Frecursive_edit () at keyboard.c:1016 #25 0x005560b8 in main (argc=1, argv=0x7fffe840) at emacs.c:1833 Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, using 1.11 brings back the crashes. I didn't csup between those versions and thus don't have 1.10 in git, but given that it's a style change it shouldn't matter. I'm using amd64 and so far I only noticed the problem with emacs. Is anyone else seeing this? Fabian signature.asc Description: PGP signature
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
On 08/27/2010 12:21, Fabian Keil wrote: The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. It aborts on exit (C-x C-c) after receiving SIGBUS: r211704 was just a style(9) fix and should coincide with cvs/1.10 that your talking about. r211706 or cvs/1.11 is the culprit that has caused your problem but I have no way to verify that here without merging it locally. If this is the case please mark the MFC of r211706 cvs/1.11 as a do-not-do. Regards, -- jhell,v ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. It aborts on exit (C-x C-c) after receiving SIGBUS: f...@r500 ~ $gdb emacs GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 amd64-marcel-freebsd... (gdb) run Starting program: /usr/local/bin/emacs [New LWP 100281] [New Thread 1260600 (LWP 100281)] Program received signal SIGBUS, Bus error. [Switching to Thread 1260600 (LWP 100281)] 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 (gdb) where #0 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 #1 0x000803038abb in __pthread_cxa_finalize () from /lib/libthr.so.3 #2 0x0008045bdfa7 in __cxa_finalize () from /lib/libc.so.7 #3 0x0008045682c7 in exit () from /lib/libc.so.7 #4 0x00556817 in Fkill_emacs (arg=Could not find the frame base for Fkill_emacs. ) at emacs.c:2146 #5 0x00600ec0 in Ffuncall (nargs=1, args=0x7fffc880) at eval.c:3024 #6 0x00658d47 in Fbyte_code (bytestr=8602321, vector=8602357, maxdepth=20) at bytecode.c:680 #7 0x006017e6 in funcall_lambda (fun=8602229, nargs=0, arg_vector=0x7fffcdc8) at eval.c:3211 #8 0x006011e0 in Ffuncall (nargs=1, args=0x7fffcdc0) at eval.c:3070 #9 0x00658d47 in Fbyte_code (bytestr=9558105, vector=9558141, maxdepth=20) at bytecode.c:680 #10 0x006017e6 in funcall_lambda (fun=9558029, nargs=1, arg_vector=0x7fffd358) at eval.c:3211 #11 0x006011e0 in Ffuncall (nargs=2, args=0x7fffd350) at eval.c:3070 #12 0x005fb954 in Fcall_interactively (function=11961778, record_flag=11544578, keys=20138021) at callint.c:869 #13 0x00600f36 in Ffuncall (nargs=4, args=0x7fffd760) at eval.c:3030 #14 0x006008fd in call3 (fn=11756290, arg1=11961778, arg2=11544578, arg3=20138021) at eval.c:2850 #15 0x0056b7ac in Fcommand_execute (cmd=11961778, record_flag=11544578, keys=20138021, special=11544674) at keyboard.c:10507 #16 0x0055cc69 in read_char (commandflag=1, nmaps=2, maps=0x7fffdb70, prev_event=11544578, used_mouse_menu=0x7fffded4, end_time=0x0) at keyboard.c:3166 #17 0x0056880e in read_key_sequence (keybuf=0x7fffe280, bufsize=30, prompt=11544578, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9512 #18 0x00558a33 in command_loop_1 () at keyboard.c:1643 #19 0x005fe0aa in internal_condition_case (bfun=0x5586a0 command_loop_1, handlers=11629954, hfun=0x557f90 cmd_error) at eval.c:1490 #20 0x0055836a in command_loop_2 () at keyboard.c:1360 #21 0x005fda2c in internal_catch (tag=11621170, func=0x558350 command_loop_2, arg=11544578) at eval.c:1226 #22 0x00558320 in command_loop () at keyboard.c:1339 #23 0x00557a85 in recursive_edit_1 () at keyboard.c:954 #24 0x00557c45 in Frecursive_edit () at keyboard.c:1016 #25 0x005560b8 in main (argc=1, argv=0x7fffe840) at emacs.c:1833 Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, using 1.11 brings back the crashes. I didn't csup between those versions and thus don't have 1.10 in git, but given that it's a style change it shouldn't matter. I'm using amd64 and so far I only noticed the problem with emacs. Is anyone else seeing this? Reverting the atexit change might cover the issue in some other place. Please build and install rtld, libc and libthr with symbolic debug information. On of the way to do this is to: cd /usr/src/libexec/rtld-elf make obj make depend make all install DEBUG_FLAGS=-g cd ../../lib/libc make obj make depend make all install DEBUG_FLAGS=-g cd ../../lib/libthr make obj make depend make all install DEBUG_FLAGS=-g Then, reproduce the crash and get bt full output from the core. I may need some further information after that. Thank you for the report. pgpeYbDV5z7nJ.pgp Description: PGP signature
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
Kostik Belousov kostik...@gmail.com wrote: On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. It aborts on exit (C-x C-c) after receiving SIGBUS: f...@r500 ~ $gdb emacs GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 amd64-marcel-freebsd... (gdb) run Starting program: /usr/local/bin/emacs [New LWP 100281] [New Thread 1260600 (LWP 100281)] Program received signal SIGBUS, Bus error. [Switching to Thread 1260600 (LWP 100281)] 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 (gdb) where #0 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 #1 0x000803038abb in __pthread_cxa_finalize () from /lib/libthr.so.3 #2 0x0008045bdfa7 in __cxa_finalize () from /lib/libc.so.7 #3 0x0008045682c7 in exit () from /lib/libc.so.7 #4 0x00556817 in Fkill_emacs (arg=Could not find the frame base for Fkill_emacs. ) at emacs.c:2146 #5 0x00600ec0 in Ffuncall (nargs=1, args=0x7fffc880) at eval.c:3024 #6 0x00658d47 in Fbyte_code (bytestr=8602321, vector=8602357, maxdepth=20) at bytecode.c:680 #7 0x006017e6 in funcall_lambda (fun=8602229, nargs=0, arg_vector=0x7fffcdc8) at eval.c:3211 #8 0x006011e0 in Ffuncall (nargs=1, args=0x7fffcdc0) at eval.c:3070 #9 0x00658d47 in Fbyte_code (bytestr=9558105, vector=9558141, maxdepth=20) at bytecode.c:680 #10 0x006017e6 in funcall_lambda (fun=9558029, nargs=1, arg_vector=0x7fffd358) at eval.c:3211 #11 0x006011e0 in Ffuncall (nargs=2, args=0x7fffd350) at eval.c:3070 #12 0x005fb954 in Fcall_interactively (function=11961778, record_flag=11544578, keys=20138021) at callint.c:869 #13 0x00600f36 in Ffuncall (nargs=4, args=0x7fffd760) at eval.c:3030 #14 0x006008fd in call3 (fn=11756290, arg1=11961778, arg2=11544578, arg3=20138021) at eval.c:2850 #15 0x0056b7ac in Fcommand_execute (cmd=11961778, record_flag=11544578, keys=20138021, special=11544674) at keyboard.c:10507 #16 0x0055cc69 in read_char (commandflag=1, nmaps=2, maps=0x7fffdb70, prev_event=11544578, used_mouse_menu=0x7fffded4, end_time=0x0) at keyboard.c:3166 #17 0x0056880e in read_key_sequence (keybuf=0x7fffe280, bufsize=30, prompt=11544578, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9512 #18 0x00558a33 in command_loop_1 () at keyboard.c:1643 #19 0x005fe0aa in internal_condition_case (bfun=0x5586a0 command_loop_1, handlers=11629954, hfun=0x557f90 cmd_error) at eval.c:1490 #20 0x0055836a in command_loop_2 () at keyboard.c:1360 #21 0x005fda2c in internal_catch (tag=11621170, func=0x558350 command_loop_2, arg=11544578) at eval.c:1226 #22 0x00558320 in command_loop () at keyboard.c:1339 #23 0x00557a85 in recursive_edit_1 () at keyboard.c:954 #24 0x00557c45 in Frecursive_edit () at keyboard.c:1016 #25 0x005560b8 in main (argc=1, argv=0x7fffe840) at emacs.c:1833 Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, using 1.11 brings back the crashes. I didn't csup between those versions and thus don't have 1.10 in git, but given that it's a style change it shouldn't matter. I'm using amd64 and so far I only noticed the problem with emacs. Is anyone else seeing this? Reverting the atexit change might cover the issue in some other place. Please build and install rtld, libc and libthr with symbolic debug information. On of the way to do this is to: cd /usr/src/libexec/rtld-elf make obj make depend make all install DEBUG_FLAGS=-g cd ../../lib/libc make obj make depend make all install DEBUG_FLAGS=-g cd ../../lib/libthr make obj make depend make all install DEBUG_FLAGS=-g Then, reproduce the crash and get bt full output from the core. I may need some further information after that. #0 0x0008045dd44c in kill () at kill.S:3 3 RSYSCALL(kill) [New Thread 1260600 (LWP 100244)] (gdb) bt full #0 0x0008045dd44c in kill () at kill.S:3 No locals. #1 0x005545c0 in fatal_error_signal (sig=10) at emacs.c:402 No locals. #2 signal handler called No symbol table info available. #3 __elf_phdr_match_addr (phdr_info=0x7fffcf90, addr=0x69ba20) at /usr/src/lib/libc/gen/elf_utils.c:39 i = 109 #4 0x000803038fdb in __pthread_cxa_finalize (phdr_info=0x7fffcf90) at /usr/src/lib/libthr/thread/thr_fork.c:109 af = (struct pthread_atfork *) 0xe1e7c0
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
On Fri, Aug 27, 2010 at 09:25:34PM +0200, Fabian Keil wrote: Kostik Belousov kostik...@gmail.com wrote: On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. It aborts on exit (C-x C-c) after receiving SIGBUS: f...@r500 ~ $gdb emacs GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 amd64-marcel-freebsd... (gdb) run Starting program: /usr/local/bin/emacs [New LWP 100281] [New Thread 1260600 (LWP 100281)] Program received signal SIGBUS, Bus error. [Switching to Thread 1260600 (LWP 100281)] 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 (gdb) where #0 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 #1 0x000803038abb in __pthread_cxa_finalize () from /lib/libthr.so.3 #2 0x0008045bdfa7 in __cxa_finalize () from /lib/libc.so.7 #3 0x0008045682c7 in exit () from /lib/libc.so.7 #4 0x00556817 in Fkill_emacs (arg=Could not find the frame base for Fkill_emacs. ) at emacs.c:2146 #5 0x00600ec0 in Ffuncall (nargs=1, args=0x7fffc880) at eval.c:3024 #6 0x00658d47 in Fbyte_code (bytestr=8602321, vector=8602357, maxdepth=20) at bytecode.c:680 #7 0x006017e6 in funcall_lambda (fun=8602229, nargs=0, arg_vector=0x7fffcdc8) at eval.c:3211 #8 0x006011e0 in Ffuncall (nargs=1, args=0x7fffcdc0) at eval.c:3070 #9 0x00658d47 in Fbyte_code (bytestr=9558105, vector=9558141, maxdepth=20) at bytecode.c:680 #10 0x006017e6 in funcall_lambda (fun=9558029, nargs=1, arg_vector=0x7fffd358) at eval.c:3211 #11 0x006011e0 in Ffuncall (nargs=2, args=0x7fffd350) at eval.c:3070 #12 0x005fb954 in Fcall_interactively (function=11961778, record_flag=11544578, keys=20138021) at callint.c:869 #13 0x00600f36 in Ffuncall (nargs=4, args=0x7fffd760) at eval.c:3030 #14 0x006008fd in call3 (fn=11756290, arg1=11961778, arg2=11544578, arg3=20138021) at eval.c:2850 #15 0x0056b7ac in Fcommand_execute (cmd=11961778, record_flag=11544578, keys=20138021, special=11544674) at keyboard.c:10507 #16 0x0055cc69 in read_char (commandflag=1, nmaps=2, maps=0x7fffdb70, prev_event=11544578, used_mouse_menu=0x7fffded4, end_time=0x0) at keyboard.c:3166 #17 0x0056880e in read_key_sequence (keybuf=0x7fffe280, bufsize=30, prompt=11544578, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9512 #18 0x00558a33 in command_loop_1 () at keyboard.c:1643 #19 0x005fe0aa in internal_condition_case (bfun=0x5586a0 command_loop_1, handlers=11629954, hfun=0x557f90 cmd_error) at eval.c:1490 #20 0x0055836a in command_loop_2 () at keyboard.c:1360 #21 0x005fda2c in internal_catch (tag=11621170, func=0x558350 command_loop_2, arg=11544578) at eval.c:1226 #22 0x00558320 in command_loop () at keyboard.c:1339 #23 0x00557a85 in recursive_edit_1 () at keyboard.c:954 #24 0x00557c45 in Frecursive_edit () at keyboard.c:1016 #25 0x005560b8 in main (argc=1, argv=0x7fffe840) at emacs.c:1833 Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, using 1.11 brings back the crashes. I didn't csup between those versions and thus don't have 1.10 in git, but given that it's a style change it shouldn't matter. I'm using amd64 and so far I only noticed the problem with emacs. Is anyone else seeing this? Reverting the atexit change might cover the issue in some other place. Please build and install rtld, libc and libthr with symbolic debug information. On of the way to do this is to: cd /usr/src/libexec/rtld-elf make obj make depend make all install DEBUG_FLAGS=-g cd ../../lib/libc make obj make depend make all install DEBUG_FLAGS=-g cd ../../lib/libthr make obj make depend make all install DEBUG_FLAGS=-g Then, reproduce the crash and get bt full output from the core. I may need some further information after that. #0 0x0008045dd44c in kill () at kill.S:3 3 RSYSCALL(kill) [New Thread 1260600 (LWP 100244)] (gdb) bt full #0 0x0008045dd44c in kill () at kill.S:3 No locals. #1 0x005545c0 in fatal_error_signal (sig=10) at emacs.c:402 No locals. #2 signal handler called No symbol table info available. #3 __elf_phdr_match_addr (phdr_info=0x7fffcf90, addr=0x69ba20) at /usr/src/lib/libc/gen/elf_utils.c:39 i = 109 #4
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
Kostik Belousov kostik...@gmail.com wrote:
On Fri, Aug 27, 2010 at 09:25:34PM +0200, Fabian Keil wrote:
Kostik Belousov kostik...@gmail.com wrote:
On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote:
The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for
me. It aborts on exit (C-x C-c) after receiving SIGBUS:
Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again,
using 1.11 brings back the crashes. I didn't csup between those
versions and thus don't have 1.10 in git, but given that it's a
style change it shouldn't matter.
I'm using amd64 and so far I only noticed the problem with emacs.
Is anyone else seeing this?
Reverting the atexit change might cover the issue in some other place.
Please build and install rtld, libc and libthr with symbolic
debug information. On of the way to do this is to:
cd /usr/src/libexec/rtld-elf
make obj make depend make all install DEBUG_FLAGS=-g
cd ../../lib/libc
make obj make depend make all install DEBUG_FLAGS=-g
cd ../../lib/libthr
make obj make depend make all install DEBUG_FLAGS=-g
Then, reproduce the crash and get bt full output from the
core. I may need some further information after that.
#0 0x0008045dd44c in kill () at kill.S:3
3 RSYSCALL(kill)
[New Thread 1260600 (LWP 100244)]
(gdb) bt full
#0 0x0008045dd44c in kill () at kill.S:3
No locals.
#1 0x005545c0 in fatal_error_signal (sig=10) at emacs.c:402
No locals.
#2 signal handler called
No symbol table info available.
#3 __elf_phdr_match_addr (phdr_info=0x7fffcf90, addr=0x69ba20) at
/usr/src/lib/libc/gen/elf_utils.c:39
i = 109
#4 0x000803038fdb in __pthread_cxa_finalize (phdr_info=0x7fffcf90)
at /usr/src/lib/libthr/thread/thr_fork.c:109
af = (struct pthread_atfork *) 0xe1e7c0
af1 = (struct pthread_atfork *) 0x0
#5 0x0008045be0a7 in __cxa_finalize (dso=0x0) at
/usr/src/lib/libc/stdlib/atexit.c:204
phdr_info = {dlpi_addr = 0, dlpi_name = 0x7fffd080 `\177,
dlpi_phdr = 0x7fffe848, dlpi_phnum = 59448, dlpi_adds = 0, dlpi_subs =
34367899629,
dlpi_tls_modid = 15046784, dlpi_tls_data = 0x12c2538}
p = (struct atexit *) 0x0
fn = {fn_type = 1, fn_ptr = {std_func = 0x8007ccff0 rtld_exit,
cxa_func = 0x8007ccff0 rtld_exit}, fn_arg = 0x0, fn_dso = 0x0}
n = -1
has_phdr = 0
#6 0x0008045683c7 in exit (status=0) at
/usr/src/lib/libc/stdlib/exit.c:67
No locals.
#7 0x00556817 in Fkill_emacs (arg=Could not find the frame base
for Fkill_emacs.
) at emacs.c:2146
gcpro1 = Could not find the frame base for Fkill_emacs.
Current language: auto; currently asm
Ewww. Please try this.
diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c
index 97cf234..511172a 100644
--- a/lib/libc/stdlib/atexit.c
+++ b/lib/libc/stdlib/atexit.c
@@ -200,6 +200,6 @@ __cxa_finalize(void *dso)
if (dso == NULL)
_MUTEX_DESTROY(atexit_mutex);
- if (__pthread_cxa_finalize != NULL)
+ if (has_phdr __pthread_cxa_finalize != NULL)
__pthread_cxa_finalize(phdr_info);
}
That fixed it. Thanks a lot.
Fabian
signature.asc
Description: PGP signature
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
On Fri, Aug 27, 2010 at 09:46:35PM +0200, Fabian Keil wrote: diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c index 97cf234..511172a 100644 --- a/lib/libc/stdlib/atexit.c +++ b/lib/libc/stdlib/atexit.c @@ -200,6 +200,6 @@ __cxa_finalize(void *dso) if (dso == NULL) _MUTEX_DESTROY(atexit_mutex); - if (__pthread_cxa_finalize != NULL) + if (has_phdr __pthread_cxa_finalize != NULL) __pthread_cxa_finalize(phdr_info); } That fixed it. Thanks a lot. Thank for your help, fixed in r211894. pgpr3GJ9fm8d0.pgp Description: PGP signature
RE: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd
-Original Message- From: Patrick Stinson [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 5:55 PM To: Patrick Stinson Subject: RE: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd no, after a new install, I'm still getting the link errors for the undefined reference to ostream members. I've got no idea. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Patrick Stinson Sent: Sunday, December 01, 2002 3:31 PM To: Garrett Rooney Cc: freebsd-current Subject: RE: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd mmm, yeah, I might try removing all of the headers and doing another installworld -Original Message- From: Garrett Rooney [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 2:48 AM To: Patrick Stinson Cc: freebsd-current Subject: Re: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd On Sunday, December 1, 2002, at 09:40 AM, Patrick Stinson wrote: After doing a complete upgrade (on a clean system, no less) from 4.4 5.0, I;ve found that every now and again I get the same compiler error regarding undefined references to cerr, ostream operators, etc. I'm building the gcc33 port assuming it's a compat. issue with the libs, but has anyone else seen this? Also, all versions of emacs sparatically seg fault upon startup. thanks. i don't know about the emacs thing, but the compiler errors sound like the kind of thing you see when you try to link a c++ program with gcc instead of g++. also, there are some issues with old header files from a 4.X system that's been updated to 5.0. the details should be in UPDATING. -garrett -- garrett rooneyRemember, any design flaw you're [EMAIL PROTECTED] sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd
After doing a complete upgrade (on a clean system, no less) from 4.4 5.0, I;ve found that every now and again I get the same compiler error regarding undefined references to cerr, ostream operators, etc. I'm building the gcc33 port assuming it's a compat. issue with the libs, but has anyone else seen this? Also, all versions of emacs sparatically seg fault upon startup. thanks. -P patrickkidd.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd
sorry, here is one of the compiler errors: $ make c++ Main.o Temperature.o Xpm.o -o Temperature.app -L/usr/X11R6/lib -lXpm -lXext -lX11 Temperature.o: In function `catchChildExit(int)': Temperature.o(.text+0x73): undefined reference to `cerr' Temperature.o(.text+0x80): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x90): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x98): undefined reference to `endl(ostream)' Temperature.o: In function `Temperature::Temperature(int, char**)': Temperature.o(.text+0x540): undefined reference to `cerr' Temperature.o(.text+0x54d): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x55d): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x56f): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x577): undefined reference to `endl(ostream)' Temperature.o(.text+0x58a): undefined reference to `cerr' Temperature.o(.text+0x597): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x5a7): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x5af): undefined reference to `endl(ostream)' Temperature.o(.text+0x66f): undefined reference to `cerr' Temperature.o(.text+0x67c): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x68c): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x6d4): undefined reference to `cerr' Temperature.o(.text+0x6e1): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x6f1): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x709): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x719): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x721): undefined reference to `endl(ostream)' Temperature.o(.text+0x79e): undefined reference to `cerr' Temperature.o(.text+0x7ab): undefined reference to `ostream::operator(char const*)' Temperature.o: In function `Temperature::Temperature(int, char**)': Temperature.o(.text+0xcd0): undefined reference to `cerr' Temperature.o(.text+0xcdd): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xced): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xcff): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xd07): undefined reference to `endl(ostream)' Temperature.o(.text+0xd1a): undefined reference to `cerr' Temperature.o(.text+0xd27): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xd37): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xd3f): undefined reference to `endl(ostream)' Temperature.o(.text+0xdff): undefined reference to `cerr' Temperature.o(.text+0xe0c): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xe1c): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xe64): undefined reference to `cerr' Temperature.o(.text+0xe71): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xe81): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xe99): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xea9): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xeb1): undefined reference to `endl(ostream)' Temperature.o(.text+0xf2e): undefined reference to `cerr' Temperature.o(.text+0xf3b): undefined reference to `ostream::operator(char const*)' Temperature.o: In function `Temperature::tryHelp(char*)': Temperature.o(.text+0xfd9): undefined reference to `cerr' Temperature.o(.text+0xfde): undefined reference to `endl(ostream)' Temperature.o(.text+0xfee): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0xffd): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x100d): undefined reference to `ostream::operator(char const*)' Temperature.o(.text+0x1015): undefined reference to `endl(ostream)' -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Patrick Stinson Sent: Sunday, December 01, 2002 2:40 PM To: freebsd-current Subject: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd After doing a complete upgrade (on a clean system, no less) from 4.4 5.0, I;ve found that every now and again I get the same compiler error regarding undefined references to cerr, ostream operators, etc. I'm building the gcc33 port assuming it's a compat. issue with the libs, but has anyone else seen this? Also, all versions of emacs sparatically seg fault upon startup. thanks. -P patrickkidd.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd
On Sunday, December 1, 2002, at 09:40 AM, Patrick Stinson wrote: After doing a complete upgrade (on a clean system, no less) from 4.4 5.0, I;ve found that every now and again I get the same compiler error regarding undefined references to cerr, ostream operators, etc. I'm building the gcc33 port assuming it's a compat. issue with the libs, but has anyone else seen this? Also, all versions of emacs sparatically seg fault upon startup. thanks. i don't know about the emacs thing, but the compiler errors sound like the kind of thing you see when you try to link a c++ program with gcc instead of g++. also, there are some issues with old header files from a 4.X system that's been updated to 5.0. the details should be in UPDATING. -garrett -- garrett rooneyRemember, any design flaw you're [EMAIL PROTECTED] sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd
mmm, yeah, I might try removing all of the headers and doing another installworld -Original Message- From: Garrett Rooney [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 2:48 AM To: Patrick Stinson Cc: freebsd-current Subject: Re: Emacs errors, undefined references to osream::[*] after 4.4 - 5.0 upgd On Sunday, December 1, 2002, at 09:40 AM, Patrick Stinson wrote: After doing a complete upgrade (on a clean system, no less) from 4.4 5.0, I;ve found that every now and again I get the same compiler error regarding undefined references to cerr, ostream operators, etc. I'm building the gcc33 port assuming it's a compat. issue with the libs, but has anyone else seen this? Also, all versions of emacs sparatically seg fault upon startup. thanks. i don't know about the emacs thing, but the compiler errors sound like the kind of thing you see when you try to link a c++ program with gcc instead of g++. also, there are some issues with old header files from a 4.X system that's been updated to 5.0. the details should be in UPDATING. -garrett -- garrett rooneyRemember, any design flaw you're [EMAIL PROTECTED] sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
emacs?
I'm confused about the -CURRENT emacs breakage. Is this an O.S. breakage which will eventually be fixed, or a permanent change which will require a patch to emacs? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage. Is this an O.S. breakage which will eventually be fixed, or a permanent change which will require a patch to emacs? Thanks. This is a permanent change. The new binutils defaults have changed to generate binaries, which are more convenient for runtime linker to relocate. The code in [x]emacs is not prepared to deal with the change in format and thus will have to be fixed, or the while issue could be worked around by linking [x]emacs binary with -znocombreloc. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
Alexander Kabaev wrote: On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage... ...The code in [x]emacs is not prepared to deal with the change in format and thus will have to be fixed, or the while issue could be worked around by linking [x]emacs binary with -znocombreloc. Hmm. I tried make LDFLAGS=-znocombreloc but that doesn't fix the crashes. Am I doing the wrong thing? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
On 22-Oct-2002 walt wrote: Alexander Kabaev wrote: On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage... ...The code in [x]emacs is not prepared to deal with the change in format and thus will have to be fixed, or the while issue could be worked around by linking [x]emacs binary with -znocombreloc. Hmm. I tried make LDFLAGS=-znocombreloc but that doesn't fix the crashes. Am I doing the wrong thing? Try LDFLAGS=-Wl,-znocombreloc, that's what I used to get xemacs working. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
John Baldwin wrote: On 22-Oct-2002 walt wrote: Alexander Kabaev wrote: On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage... ...could be worked around by linking [x]emacs binary with -znocombreloc. Hmm. I tried make LDFLAGS=-znocombreloc but that doesn't fix the crashes. Try LDFLAGS=-Wl,-znocombreloc, that's what I used to get xemacs working. Yes, that worked, thanks. I found I had to edit the generated Makefile in /usr/ports/editors/emacs20/work/emacs-20.7 because 'configure' complained about the LDFLAGS, otherwise. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
emacs problems?
I'm having problems with emacs 20.7 running under X: #emacs Fatal error (11).Segmentation fault (core dumped) but emacs -nw works fine (i.e. without X). This started after doing a portupgrade -fa to solve the _sF symbol problem. I've recompiled every package that emacs depends on and still no change. The backtrace isn't very helpful. I suppose I need to build emacs with debugging enabled? Any hints how to do that? Anyone else seeing this problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs problems?
On Fri, 18 Oct 2002 08:00:19 -0700 walt [EMAIL PROTECTED] wrote: I suppose I need to build emacs with debugging enabled? Any hints how to do that? Anyone else seeing this problem? xemacs dies here. Global variables are getting corrupted somehow during startup. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: emacs problems?
On 18-Oct-2002 walt wrote: I'm having problems with emacs 20.7 running under X: #emacs Fatal error (11).Segmentation fault (core dumped) but emacs -nw works fine (i.e. without X). This started after doing a portupgrade -fa to solve the _sF symbol problem. I've recompiled every package that emacs depends on and still no change. The backtrace isn't very helpful. I suppose I need to build emacs with debugging enabled? Any hints how to do that? Anyone else seeing this problem? Same exact problem with xemacs. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs problems?
On Fri, Oct 18, 2002 at 08:00:19AM -0700, walt wrote: Anyone else seeing this problem? The only issue I have with emacs (I'm using xemacs 21.1.14) is that it hangs quite often. Usually when I do a lot of mouse scrolling. This seems to be a recent thing. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs problems?
On 18-Oct-2002 Alex Zepeda wrote: On Fri, Oct 18, 2002 at 08:00:19AM -0700, walt wrote: Anyone else seeing this problem? The only issue I have with emacs (I'm using xemacs 21.1.14) is that it hangs quite often. Usually when I do a lot of mouse scrolling. This seems to be a recent thing. This is due to the ucontext_t/FPU breakage in current. If you recompile a new xemacs though then xemacs won't even start w/o getting a sig 11 in graphical mode. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
emacs-20.6 core dumps in FreeBSD-4.0-RELEASE
Hi, I installed the package for emacs-20.6 on my machine running FreeBSD-4.0-RELEASE and it core dumps upon issuing the command 'emacs -nw'. This package was obtained from: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.0-RELEASE/packages/All/emacs-20.6.tgz However, it runs fine if I instead install the package from: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/3.4-STABLE/packages/All/emacs-20.6.tgz The difference between the above two packages seems to be that the former links against libc.so.4 while the latter links against libc.so.3 (in /usr/lib/compat). It seems that libc.so.4 in FreeBSD-4.0-RELEASE has some bugs. I also downloaded emacs-20.6 from: ftp://ftp.gnu.org/pub/gnu/emacs/emacs-20.6.tar.gz and compiled it. It has the same 'core dump' problem - it also links against libc.so.4. Here's the output of 'uname -a' for my machine: FreeBSD luzern.cs.rice.edu 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Thu Mar 16 19:14:31 CST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/LUZERN i386 - Mohit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
"Peter S. Housel" [EMAIL PROTECTED] writes: Ever since the libtermcap / libncurses consolidation, change emacs has problems positioning the cursor and properly updating the screen for character-only devices like the console. It also affects the display in an xterm in non-X mode, i.e., when DISPLAY is *not* set. ... I filed a bug report for this. I fixed it in Emacs with the following patch. I think it's a FreeBSD bug, though. Good detective work, Peter. So is the bug in FreeBSD or Emacs? The new man page for tgetstr says: Bugs If you call tgetstr to fetch ca or any other parameterized string, be aware that it will be returned in terminfo notation, not the older and not-quite-compatible termcap notation. This won't cause problems if all you do with it is call tgoto or tparm, which both expand terminfo-style. Emacs tries to expand the string itself rather than by calling tparm and we've surprised it by returning the string in terminfo style rather than termcap style. Here's an alternative patch that forces Emacs to use the library versions of tparm and tgoto to do the decoding rather than rolling its own. Put this in /usr/ports/editors/emacs20/patches/patch-ce (although it really should get merged into patch-ca). It works by using the module intended for Emacs running on terminfo machines (ie. it uses terminfo.c rather than tparam.c). I tried this (briefly) on -current and -stable and it seems to work ok. $ cat /usr/ports/editors/emacs20/patches/patch-ce --- src/Makefile.in.origSat Oct 30 15:52:15 1999 +++ src/Makefile.in Sat Oct 30 15:55:28 1999 @@ -546,7 +546,7 @@ #define LIBS_TERMCAP termcapobj = termcap.o tparam.o #else /* LIBS_TERMCAP */ -termcapobj = tparam.o +termcapobj = terminfo.o #endif /* LIBS_TERMCAP */ #endif /* ! defined (TERMINFO) */ -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
emacs / ncurses - problem somewhere
Hi, Ever since the libtermcap / libncurses consolidation, change emacs has problems positioning the cursor and properly updating the screen for character-only devices like the console. It also affects the display in an xterm in non-X mode, i.e., when DISPLAY is *not* set. This is emacs 20.4, by the way on current as of yesterday. I've tried emacs from packages as well as a freshly built one from the ports and both exhibit the problem. Note that emacs works fine when it brings up is own window due to DISPLAY being set. Has anyone else seen this and already have a fix or know for sure whether this is an emacs bug or a FreeBSD bug? Thanks, -Brian -- Brian Dean [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
|Hi, | |Ever since the libtermcap / libncurses consolidation, change emacs has |problems positioning the cursor and properly updating the screen for |character-only devices like the console. It also affects the display |in an xterm in non-X mode, i.e., when DISPLAY is *not* set. | |This is emacs 20.4, by the way on current as of yesterday. I've tried |emacs from packages as well as a freshly built one from the ports and |both exhibit the problem. | |Note that emacs works fine when it brings up is own window due to |DISPLAY being set. | |Has anyone else seen this and already have a fix or know for sure |whether this is an emacs bug or a FreeBSD bug? Yup! And also for 19.34b... I've searched all over for the source of this problem, glad to know I'm not alone. However, it only affects one of my three -current boxes, so apparently there is bit of cruft lying around, but I haven't been able to find the sucker causing this. (mergemaster'd repeatedly) Russell | |Thanks, |-Brian |-- |Brian Dean [EMAIL PROTECTED] | | |To Unsubscribe: send mail to [EMAIL PROTECTED] |with "unsubscribe freebsd-current" in the body of the message | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
"Russell L. Carter" [EMAIL PROTECTED] writes: Yup! And also for 19.34b... I've searched all over for the source of this problem, glad to know I'm not alone. However, it only affects one of my three -current boxes, so apparently there is bit of cruft lying around, but I haven't been able to find the sucker causing this. (mergemaster'd repeatedly) Are the ones that work linked with an old version of libtermcap.so that was lying around or are they linked with the new libncurses.so.5 ? -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
Ever since the libtermcap / libncurses consolidation, change emacs has problems positioning the cursor and properly updating the screen for character-only devices like the console. It also affects the display in an xterm in non-X mode, i.e., when DISPLAY is *not* set. This is emacs 20.4, by the way on current as of yesterday. I've tried emacs from packages as well as a freshly built one from the ports and both exhibit the problem. Note that emacs works fine when it brings up is own window due to DISPLAY being set. Has anyone else seen this and already have a fix or know for sure whether this is an emacs bug or a FreeBSD bug? I filed a bug report for this. I fixed it in Emacs with the following patch. I think it's a FreeBSD bug, though. -Peter- [EMAIL PROTECTED] --- /tmp/tparam.c Fri Oct 29 12:27:03 1999 +++ tparam.cThu Oct 7 23:07:24 1999 @@ -290,6 +290,9 @@ case 'D': /* %D means weird Delta Data transformation. */ argp[0] -= 2 * (tem % 16); break; + case 'p': /* from terminfo */ + p++; + break; } } else To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
|"Russell L. Carter" [EMAIL PROTECTED] writes: | | Yup! And also for 19.34b... I've searched all over for the | source of this problem, glad to know I'm not alone. However, | it only affects one of my three -current boxes, so apparently there is | bit of cruft lying around, but I haven't been able to find | the sucker causing this. (mergemaster'd repeatedly) | |Are the ones that work linked with an old version of libtermcap.so that |was lying around or are they linked with the new libncurses.so.5 ? ldd emacs on -current with the bug: libncurses.so.5 = /usr/lib/libncurses.so.5 (0x2824a000) ldd emacs on -current without the bug (different system): libtermcap.so.2 = /usr/lib/libtermcap.so.2 (0x1828c000) Russell | |-- |Kevin Street |[EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: emacs* broken in -current (was Re: Vtable thunks with egcs)
I've found where this problem is coming from. It's in emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the version number contained in __FreeBSD__, checking for 1, 2 and 3. Of course, -current uses 4. I have found that you can check for __FreeBSD__ = 3, and it will work, but this feels a bit like a hack. I've never updated a port, so I can either get some instruction from someone to put in a patch, or let someone else do it. David Deatherage -Original Message- From: Joel Ray Holveck [mailto:jo...@gnu.org] Sent: Thursday, April 08, 1999 9:18 PM To: Steve Price Cc: Peter Jeremy; curr...@freebsd.org; po...@freebsd.org Subject: Re: emacs* broken in -current (was Re: Vtable thunks with egcs) You are absolutely right. I just tried the new version of emacs that I built on my pre-egcs box and it doesn't work on that box either. This definitely doesn't appear to be anything caused by changing to egcs. Not that it matters much but for grins I just built/installed the xemacs port and it _does_ appear to work. I've been having no problems with an Emacs 20.3 and X11R6 built in October on a -current system from April 6. (The Emacs is ELF, and built from my own sources instead of the port.) I'd like to track this down; could people give me more info privately? rms is looking at releasing a mostly bugfix Emacs, possibly tommorow, but it may be another month (he's about to leave town). I haven't been watching the changes; there may be some X-related fixes in there. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
I've found where this problem is coming from. It's in emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the version number contained in __FreeBSD__, checking for 1, 2 and 3. Of course, -current uses 4. I have found that you can check for __FreeBSD__ = 3, and it will work, but this feels a bit like a hack. I've never updated a port, so I can either get some instruction from someone to put in a patch, or let someone else do it. I'll make the patch if a committer can get it in. -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
On 9 Apr 1999, Joel Ray Holveck wrote: # I've found where this problem is coming from. It's in # emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the # version number contained in __FreeBSD__, checking for 1, 2 and 3. Of # course, -current uses 4. I have found that you can check for __FreeBSD__ = # 3, and it will work, but this feels a bit like a hack. I've never updated a # port, so I can either get some instruction from someone to put in a patch, # or let someone else do it. # # I'll make the patch if a committer can get it in. Send it to me. I'll commit it. :) BTW, good catch David! -steve # -- # Joel Ray Holveck - jo...@gnu.org #Fourth law of programming: #Anything that can go wrong wi # sendmail: segmentation violation - core dumped # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
emacs* broken in -current (was Re: Vtable thunks with egcs)
You are absolutely right. I just tried the new version of emacs that I built on my pre-egcs box and it doesn't work on that box either. This definitely doesn't appear to be anything caused by changing to egcs. Not that it matters much but for grins I just built/installed the xemacs port and it _does_ appear to work. -steve On Fri, 9 Apr 1999, Peter Jeremy wrote: # I submitted ports/10783 covering this about 2 weeks ago. The port # on the 3.1-RELEASE CD is OK, but I can't get it to work with -CURRENT. # (I suspect it's been broken for some time). # # I have tried mixing and matching the X11 libs and the problem is # in emacs, not X11. # # Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
You are absolutely right. I just tried the new version of emacs that I built on my pre-egcs box and it doesn't work on that box either. This definitely doesn't appear to be anything caused by changing to egcs. Not that it matters much but for grins I just built/installed the xemacs port and it _does_ appear to work. I've been having no problems with an Emacs 20.3 and X11R6 built in October on a -current system from April 6. (The Emacs is ELF, and built from my own sources instead of the port.) I'd like to track this down; could people give me more info privately? rms is looking at releasing a mostly bugfix Emacs, possibly tommorow, but it may be another month (he's about to leave town). I haven't been watching the changes; there may be some X-related fixes in there. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with ELF Emacs
Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: Peter Jeremy peter.jer...@auss2.alcatel.com.au writes: I'm running -current from a couple of weeks ago. I recently re-compiled XFree86 to ELF - which works, and re-compiled emacs-19.34b - which won't work with X11, though it does work inside an Xterm. I run an Elf build of Emacs 19.34b daily on a completely Elf, very up-to-date 4.0-CURRENT box with Elf XFree86 3.3.3.1. No trouble at all. I've worked out that emacs is looping in xterm.c:x_make_frame_visible. It is apparently waiting for an input event indicating the the window has been mapped. It expects to get informed of this when a signal (presumably SIGIO) invokes XTread_socket() via input_available_signal(). The only problem is that input_available_signal() never seems to get called. (I haven't been able to track down where F_ASYNC is being set/cleared yet). I'll try another make world next week and see if that helps. Looking into this, I've found a few anomolies: 1) Trying to use the new aout X11 shared libraries reports an undefined ___error. My old shared libraries are OK. I suspect this isn't a major issue. 2) Running an ELF emacs inside gdb, when I set a breakpoint on sigaction, the breakpoint is never hit. Setting a breakpoint on signal and then stepping shows that sigaction (actually _sigaction) is executed - though at a radically different address to the breakpoint. Can one of the ELF experts explain this please. (Not having breakpoints behave as expected is very off-putting). Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with ELF Emacs
Peter Jeremy peter.jer...@auss2.alcatel.com.au writes: I'm running -current from a couple of weeks ago. I recently re-compiled XFree86 to ELF - which works, and re-compiled emacs-19.34b - which won't work with X11, though it does work inside an Xterm. My old aout emacs still works (with old aout libraries - the re-compiled aout libraries seem to be missing a symbol). I run an Elf build of Emacs 19.34b daily on a completely Elf, very up-to-date 4.0-CURRENT box with Elf XFree86 3.3.3.1. No trouble at all. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with ELF Emacs
%I'm running -current from a couple of weeks ago. I recently re-compiled %XFree86 to ELF - which works, and re-compiled emacs-19.34b - which won't %work with X11, though it does work inside an Xterm. My old aout emacs %still works (with old aout libraries - the re-compiled aout libraries %seem to be missing a symbol). % %When running as an X11 client, emacs opens the window and then nothing %happens. Looking at a ktrace, it seems to be continuously sending %GetInputFocus commands to the X-server, which are being correctly %replied to (as far as I can tell). % %I haven't bumped into this problem with any other X clients. % %Has anyone else seen this, or have any ideas? Yes, and no. It happens for me only with an ssh1 forwarded xterm, with whatever the most recent emacs2 is. Checked, and fails with emacs19. Elf emacs works fine on a local xterm. Xemacs works fine. Everything else does too. At that point, I started exporting filesystems. Russell %Peter % % %To Unsubscribe: send mail to majord...@freebsd.org %with unsubscribe freebsd-current in the body of the message % To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Problems with ELF Emacs
I'm running -current from a couple of weeks ago. I recently re-compiled XFree86 to ELF - which works, and re-compiled emacs-19.34b - which won't work with X11, though it does work inside an Xterm. My old aout emacs still works (with old aout libraries - the re-compiled aout libraries seem to be missing a symbol). When running as an X11 client, emacs opens the window and then nothing happens. Looking at a ktrace, it seems to be continuously sending GetInputFocus commands to the X-server, which are being correctly replied to (as far as I can tell). I haven't bumped into this problem with any other X clients. Has anyone else seen this, or have any ideas? Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs directories in BSD.local.dist
* Just curious as to why share/emacs and share/emacs/site-lisp are created by * BSD.local.dist instead of by the emacs ports which might want to use them? * It's not a big deal, but it seems to me that these aren't useful for the * general case of someone not wanting to install an emacs port (strange as that * may sound [1]). I suspect it's for historical reasons, but it doesnt mean it * can't be removed if sufficient time is deemed to have passed. Actually it's the other way around. It's created by BSD.local.dist so that people who don't need emacs don't have to install them. :) The problem is that many ports, some of which only install .el files as a by the way, you can use this from emacs too, fall over if this directory is not around. One solution is to add RUN_DEPENDS to emacs, which causes a whole lot of unhappiness, of course. So it's either those ports create the directory themselves or let BSD.local.dist do it. The latter was infinitely easier. :) Satoshi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs directories in BSD.local.dist
On Mon, 8 Feb 1999, Satoshi Asami wrote: * Just curious as to why share/emacs and share/emacs/site-lisp are created by * BSD.local.dist instead of by the emacs ports which might want to use them? * It's not a big deal, but it seems to me that these aren't useful for the * general case of someone not wanting to install an emacs port (strange as that * may sound [1]). I suspect it's for historical reasons, but it doesnt mean it * can't be removed if sufficient time is deemed to have passed. Actually it's the other way around. It's created by BSD.local.dist so that people who don't need emacs don't have to install them. :) The problem is that many ports, some of which only install .el files as a by the way, you can use this from emacs too, fall over if this directory is not around. One solution is to add RUN_DEPENDS to emacs, which causes a whole lot of unhappiness, of course. Ahh, that makes sense. Thanks for the explanation. Kris - (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
emacs directories in BSD.local.dist
Just curious as to why share/emacs and share/emacs/site-lisp are created by BSD.local.dist instead of by the emacs ports which might want to use them? It's not a big deal, but it seems to me that these aren't useful for the general case of someone not wanting to install an emacs port (strange as that may sound [1]). I suspect it's for historical reasons, but it doesnt mean it can't be removed if sufficient time is deemed to have passed. Kris [1] Please, no editor wars :-) --- BSD.local.dist Thu Dec 24 01:54:29 1998 +++ BSD.local.dist~ Sun Feb 7 21:18:23 1999 @@ -168,10 +168,6 @@ .. doc .. -emacs -site-lisp -.. -.. examples .. misc - (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
4.0-current emacs locks up in startup
4.0-current of a few days ago. rebuilt XFree and a bunch of other stuff build emacs or emacs20 either runs fine in an x-term either freezes when started with its own window it puts up the window paints the grey menu bar freeze emacs20 stack at freeze #0 0x282c4824 in select () #1 0x28203e31 in _XWaitForReadable () #2 0x282044f4 in _XRead () #3 0x28204d6a in _XReply () #4 0x2820194b in XSync () #5 0x8089f3e in x_sync () #6 0x80826d2 in x_make_frame_visible () #7 0x805246f in Fmake_frame_visible () #8 0x80e295a in Ffuncall () #9 0x810740e in Fbyte_code () #10 0x80e2eac in funcall_lambda () #11 0x80e2aba in Ffuncall () #12 0x810740e in Fbyte_code () #13 0x80e2eac in funcall_lambda () #14 0x80e2aba in Ffuncall () #15 0x810740e in Fbyte_code () #16 0x80e2eac in funcall_lambda () #17 0x80e2aba in Ffuncall () #18 0x810740e in Fbyte_code () #19 0x80e2eac in funcall_lambda () #20 0x80e2aba in Ffuncall () #21 0x810740e in Fbyte_code () #22 0x80e2eac in funcall_lambda () #23 0x80e2c52 in apply_lambda () #24 0x80e1edd in Feval () #25 0x809134e in top_level_2 () #26 0x80e0ea0 in internal_condition_case () #27 0x8091375 in top_level_1 () #28 0x80e0b42 in internal_catch () #29 0x80912d6 in command_loop () #30 0x8090f67 in recursive_edit_1 () #31 0x809104d in Frecursive_edit () #32 0x80902ab in main () #33 0x804d519 in _start () randy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
