* i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 @ 1998-06-20 13:06 Jim Meyering 1998-07-15 0:54 ` Jim Meyering 0 siblings, 1 reply; 23+ messages in thread From: Jim Meyering @ 1998-06-20 13:06 UTC (permalink / raw) To: egcs I can build emacs-20.2 using egcs-980531, but more recent snapshots (starting a week or two ago) can no longer build it. Here's the failure I get using a recent snapshot (I updated last night): ./configure && make ... Dumping under names emacs and emacs-20.2.1 414008 pure bytes used ./emacs -q -batch -f list-load-path-shadows make[1]: *** [emacs] Segmentation Fault make[1]: Leaving directory `/d/pd/emacs/stable/emacs-20.2/src' cd leim; make -j2 all -j 1 \ CC='gcc' CFLAGS='-g -O ' CPPFLAGS='' \ LDFLAGS='' MAKE='make -j2' make[1]: Entering directory `/d/pd/emacs/stable/emacs-20.2/leim' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/d/pd/emacs/stable/emacs-20.2/leim' $ gcc -v Reading specs from /p/p/egcs-980619-21h10/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.41/specs gcc version egcs-2.91.41 19980619 (gcc2 ss-980502 experimental) $ as -v GNU assembler version 2.9.1 (i386-pc-solaris2.5.1), using BFD version 2.9.1 Building with the official snapshot, egcs-980531, worked fine. Running the failing command under the debugger didn't help me: $ gdb emacs DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x8071a4c Breakpoint 2 at 0x80a4e0a: file xterm.c, line 5241. (gdb) r -q -batch -f list-load-path-shadows Starting program: /d/pd/emacs/stable/emacs-20.2/src/emacs -q -batch -f list-load-path-shadows Breakpoint 1 at 0x801f57f0 Program received signal SIGSEGV, Segmentation fault. 0x0 in ?? () (gdb) bt #0 0x0 in ?? () #1 0x812f72c in __do_global_ctors_aux () #2 0x812f775 in _init () (gdb) Any suggestions? BTW, if I had more disk space (or if I'd been omitting symbols :-) I'd be keeping around lots more snapshots and would have been able to determine (conveniently) more precisely when gcc stopped being able to build emacs-20.2. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-06-20 13:06 i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 Jim Meyering @ 1998-07-15 0:54 ` Jim Meyering 1998-07-15 16:08 ` Dave Love ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: Jim Meyering @ 1998-07-15 0:54 UTC (permalink / raw) To: egcs; +Cc: Richard Stallman Hi, I have just confirmed that current sources as of about 980714-08h24 still exhibit the problem I reported three weeks ago. For all I know, this could be a problem with emacs, solaris5.5.1, or some tool in my build environment. Has anyone built a recent version of emacs (20.2 or newer test releases) with an egcs snapshot from June or later? Jim I wrote: | I can build emacs-20.2 using egcs-980531, but more recent snapshots | (starting a week or two ago) can no longer build it. Here's the | failure I get using a recent snapshot (I updated last night): | | ./configure && make | | ... | | Dumping under names emacs and emacs-20.2.1 | 414008 pure bytes used | ./emacs -q -batch -f list-load-path-shadows | make[1]: *** [emacs] Segmentation Fault | make[1]: Leaving directory `/d/pd/emacs/stable/emacs-20.2/src' | cd leim; make -j2 all -j 1 \ | CC='gcc' CFLAGS='-g -O ' CPPFLAGS='' \ | LDFLAGS='' MAKE='make -j2' | make[1]: Entering directory `/d/pd/emacs/stable/emacs-20.2/leim' | make[1]: Nothing to be done for `all'. | make[1]: Leaving directory `/d/pd/emacs/stable/emacs-20.2/leim' | | $ gcc -v | Reading specs from /p/p/egcs-980619-21h10/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.41/specs | gcc version egcs-2.91.41 19980619 (gcc2 ss-980502 experimental) | | $ as -v | GNU assembler version 2.9.1 (i386-pc-solaris2.5.1), using BFD version 2.9.1 | | Building with the official snapshot, egcs-980531, worked fine. | | Running the failing command under the debugger didn't help me: | | $ gdb emacs | DISPLAY = :0.0 | TERM = xterm | Breakpoint 1 at 0x8071a4c | Breakpoint 2 at 0x80a4e0a: file xterm.c, line 5241. | (gdb) r -q -batch -f list-load-path-shadows | Starting program: /d/pd/emacs/stable/emacs-20.2/src/emacs -q -batch -f list-load-path-shadows | Breakpoint 1 at 0x801f57f0 | | Program received signal SIGSEGV, Segmentation fault. | 0x0 in ?? () | (gdb) bt | #0 0x0 in ?? () | #1 0x812f72c in __do_global_ctors_aux () | #2 0x812f775 in _init () | (gdb) | | Any suggestions? | | BTW, if I had more disk space (or if I'd been omitting symbols :-) | I'd be keeping around lots more snapshots and would have been able to | determine (conveniently) more precisely when gcc stopped being able to | build emacs-20.2. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-15 0:54 ` Jim Meyering @ 1998-07-15 16:08 ` Dave Love 1998-07-16 0:32 ` Jeffrey A Law ` (2 subsequent siblings) 3 siblings, 0 replies; 23+ messages in thread From: Dave Love @ 1998-07-15 16:08 UTC (permalink / raw) To: Jim Meyering; +Cc: egcs, Jeffrey A Law, Richard Stallman I have two data: This is posted from the current pretest built with an essentially current egcs on i586-pc-linux-gnu (mostly vanilla RedHat 5.1). I've failed to build both Emacs 19.34 and 20.2 on an older x86 Debian (libc5-based) system with a similar-looking symptom to the one in question, using both gcc 2.7 and gcc 2.8. I couldn't debug it and put it down to some funny specific to that box, but perhaps it wasn't. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-15 0:54 ` Jim Meyering 1998-07-15 16:08 ` Dave Love @ 1998-07-16 0:32 ` Jeffrey A Law 1998-07-16 5:38 ` David S. Miller 1998-07-17 18:50 ` Jim Meyering 3 siblings, 0 replies; 23+ messages in thread From: Jeffrey A Law @ 1998-07-16 0:32 UTC (permalink / raw) To: Jim Meyering; +Cc: egcs, Richard Stallman In message < 87sok3zs6t.fsf@eng.ascend.com >you write: > Hi, > > I have just confirmed that current sources as of about 980714-08h24 > still exhibit the problem I reported three weeks ago. For all I know, > this could be a problem with emacs, solaris5.5.1, or some tool in my > build environment. > | Program received signal SIGSEGV, Segmentation fault. > | 0x0 in ?? () > | (gdb) bt > | #0 0x0 in ?? () > | #1 0x812f72c in __do_global_ctors_aux () > | #2 0x812f775 in _init () > | (gdb) > | > | Any suggestions? > | > | BTW, if I had more disk space (or if I'd been omitting symbols :-) > | I'd be keeping around lots more snapshots and would have been able to > | determine (conveniently) more precisely when gcc stopped being able to > | build emacs-20.2. You might try disassembling __do_global_ctors_aux to see if it looks reasonable. Or you might compile all the libgcc code & crtstuff with "-g" so that you can debug __do_global_ctors_aux. jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-15 0:54 ` Jim Meyering 1998-07-15 16:08 ` Dave Love 1998-07-16 0:32 ` Jeffrey A Law @ 1998-07-16 5:38 ` David S. Miller 1998-07-17 0:00 ` David S. Miller 1998-07-17 1:02 ` Horst von Brand 1998-07-17 18:50 ` Jim Meyering 3 siblings, 2 replies; 23+ messages in thread From: David S. Miller @ 1998-07-16 5:38 UTC (permalink / raw) To: meyering; +Cc: egcs, law, rms From: Jim Meyering <meyering@ascend.com> Date: 14 Jul 1998 22:52:42 -0500 I have just confirmed that current sources as of about 980714-08h24 still exhibit the problem I reported three weeks ago. For all I know, this could be a problem with emacs, solaris5.5.1, or some tool in my build environment. Has anyone built a recent version of emacs (20.2 or newer test releases) with an egcs snapshot from June or later? I did some research into this and I have an emacs tree which reliably reproduces the problem you are seeing, but for me on sparc-linux targets. When I vary the CFLAGS settings during the build, it changes the results, and I can get working executables. One thing you can note in the failure cases is that the impure 'temacs' is just fine and will run perfectly. In your case and in mine, running 'ldd temacs' will show all the dynamically linked libraries 'temacs' uses. However, the 'emacs' binary which crashes will be reported as static linked by ldd :-) The best I could determine using gdb was that the 'emacs' binary crashes inside of the dynamic linker very early on in execution. My best guess at this point is that current egcs emits something which results in ELF images which confuse the unexec() mechanism which emacs uses, thus making it dump corrupt executables. I'll try to track this down further as time permits. Thanks for the report. Later, David S. Miller davem@dm.cobaltmicro.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-16 5:38 ` David S. Miller @ 1998-07-17 0:00 ` David S. Miller 1998-07-17 8:59 ` Jim Meyering 1998-07-17 1:02 ` Horst von Brand 1 sibling, 1 reply; 23+ messages in thread From: David S. Miller @ 1998-07-17 0:00 UTC (permalink / raw) To: davem; +Cc: meyering, egcs, law, rms Date: Thu, 16 Jul 1998 05:36:32 -0700 From: "David S. Miller" <davem@dm.cobaltmicro.com> I'll try to track this down further as time permits. Thanks for the report. Replying to myself... Jim, I believe i have tracked it down, so could you do some experiments for me? In my case I have found that the GCSE pass mis-optimizes the code in unexelf.c When I recompile it with "-O2 -fno-gcse" I get a properly functioning emacs build. Could you try to recompile unexelf.o without any optimizations, and see if this allows the resulting emacs to work just fine? Using this, I can determine whether we are seeing the same bug. Later, David S. Miller davem@dm.cobaltmicro.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-17 0:00 ` David S. Miller @ 1998-07-17 8:59 ` Jim Meyering 1998-07-17 8:59 ` David S. Miller 0 siblings, 1 reply; 23+ messages in thread From: Jim Meyering @ 1998-07-17 8:59 UTC (permalink / raw) To: David S. Miller; +Cc: egcs, law, rms "David S. Miller" <davem@dm.cobaltmicro.com> writes: | Date: Thu, 16 Jul 1998 05:36:32 -0700 | From: "David S. Miller" <davem@dm.cobaltmicro.com> | | I'll try to track this down further as time permits. Thanks for the | report. | | Replying to myself... | | Jim, I believe i have tracked it down, so could you do some | experiments for me? | | In my case I have found that the GCSE pass mis-optimizes the code in | unexelf.c When I recompile it with "-O2 -fno-gcse" I get a properly | functioning emacs build. | | Could you try to recompile unexelf.o without any optimizations, and | see if this allows the resulting emacs to work just fine? | | Using this, I can determine whether we are seeing the same bug. Thanks! Unfortunately, even compiling all of emacs with -g (or with empty CFLAGS) didn't change the result: Loading loaddefs.el... Loading vc-hooks (compiled)... Loading ediff-hook (compiled)... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under names emacs and emacs-20.2.2 414008 pure bytes used ./emacs -q -batch -f list-load-path-shadows make: *** [emacs] Segmentation Fault I'm pretty sure that whatever it is about egcs that provokes this was introduced in the first two weeks of June. The 980531 snapshot compiled it fine, and the first time I noticed the problem was about two weeks later. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-17 8:59 ` Jim Meyering @ 1998-07-17 8:59 ` David S. Miller 1998-07-18 2:10 ` Jim Meyering 0 siblings, 1 reply; 23+ messages in thread From: David S. Miller @ 1998-07-17 8:59 UTC (permalink / raw) To: meyering; +Cc: egcs, law, rms From: Jim Meyering <meyering@ascend.com> 414008 pure bytes used ./emacs -q -batch -f list-load-path-shadows make: *** [emacs] Segmentation Fault I'm pretty sure that whatever it is about egcs that provokes this was introduced in the first two weeks of June. The 980531 snapshot compiled it fine, and the first time I noticed the problem was about two weeks later. Thanks for the further datapoints. I am still convinced that something is going wrong with unexec when compiled with egcs. The evidence in your crash indicates this to me. I ask for one further experiment if you don't mind. Can you try compiling just unexelf.o with a working gcc, leave the rest the same (compiled with egcs which causes the crashes) and tell me the results. Also, it would be very useful if you could take the crashing emacs binary and run it under gdb, and look around for clues as to where it is crashing. I would not be surprised if you find it crashed somewhere in the middle of the solaris dynamic linker, or some place similar. Thanks again for the help so far. Later, David S. Miller davem@dm.cobaltmicro.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-17 8:59 ` David S. Miller @ 1998-07-18 2:10 ` Jim Meyering 1998-07-17 22:28 ` Jeffrey A Law 1998-08-16 23:08 ` Jim Meyering 0 siblings, 2 replies; 23+ messages in thread From: Jim Meyering @ 1998-07-18 2:10 UTC (permalink / raw) To: David S. Miller; +Cc: egcs, law, rms "David S. Miller" <davem@dm.cobaltmicro.com> writes: | From: Jim Meyering <meyering@ascend.com> | | 414008 pure bytes used | ./emacs -q -batch -f list-load-path-shadows | make: *** [emacs] Segmentation Fault | | I'm pretty sure that whatever it is about egcs that provokes | this was introduced in the first two weeks of June. The 980531 | snapshot compiled it fine, and the first time I noticed the problem | was about two weeks later. | | Thanks for the further datapoints. | | I am still convinced that something is going wrong with unexec when | compiled with egcs. The evidence in your crash indicates this to me. | | I ask for one further experiment if you don't mind. Can you try | compiling just unexelf.o with a working gcc, leave the rest the same | (compiled with egcs which causes the crashes) and tell me the results. | | Also, it would be very useful if you could take the crashing emacs | binary and run it under gdb, and look around for clues as to where it | is crashing. I would not be surprised if you find it crashed | somewhere in the middle of the solaris dynamic linker, or some place | similar. I compiled unexelf.c using gcc-2.7.2.2 (with which I can build a working emacs-20.2), and tried to rebuild. Still to no avail. $ gdb emacs DISPLAY = :0.0 TERM = xterm Breakpoint 1 at 0x8071a90 Breakpoint 2 at 0x80c2055: file xterm.c, line 5241. (gdb) r -q -batch -f list-load-path-shadows Starting program: /d/pd/emacs/stable/emacs-20.2/src/emacs -q -batch -f list-load- path-shadows Breakpoint 1 at 0x801f57f0 Program received signal SIGSEGV, Segmentation fault. 0x0 in ?? () (gdb) w #0 0x0 in ?? () #1 0x818ced4 in __do_global_ctors_aux () #2 0x818cf15 in _init () But it seems crtstuff.c (__do_global_ctors_aux) can't be compiled with -g, so here's some assembly. Breakpoint 3, 0x818cf00 in _init () (gdb) disas 0x818cf00 0x818cf21 Dump of assembler code from 0x818cf00 to 0x818cf4f: 0x818cf00 <_init>: call 0x807309c <frame_dummy> 0x818cf05 <_init+5>: leal 0x0(%esi,1),%esi 0x818cf09 <_init+9>: leal 0x0(%edi,1),%edi 0x818cf10 <_init+16>: call 0x818ceb0 <__do_global_ctors_aux> 0x818cf15 <_init+21>: leal 0x0(%esi,1),%esi 0x818cf19 <_init+25>: leal 0x0(%edi,1),%edi 0x818cf20 <_init+32>: ret $0x0 End of assembler dump. stepping throught that, I made it into __register_frame_info and back to 0x818cf05. thence into __do_global_ctors_aux: 0x818cf10 in _init () (gdb) 0x818ceb0 in __do_global_ctors_aux () (gdb) disas 0x818ceb0 0x818cef0 Dump of assembler code from 0x818ceb0 to 0x818cef0: 0x818ceb0 <__do_global_ctors_aux>: pushl %ebp 0x818ceb1 <__do_global_ctors_aux+1>: movl %esp,%ebp 0x818ceb3 <__do_global_ctors_aux+3>: pushl %esi 0x818ceb4 <__do_global_ctors_aux+4>: pushl %ebx 0x818ceb5 <__do_global_ctors_aux+5>: call 0x818ceba <__do_global_ctors_aux+10> 0x818ceba <__do_global_ctors_aux+10>: popl %ebx 0x818cebb <__do_global_ctors_aux+11>: addl $0x116ee,%ebx 0x818cec1 <__do_global_ctors_aux+17>: leal 0x6f688(%ebx),%eax 0x818cec7 <__do_global_ctors_aux+23>: leal 0xfffffffc(%eax),%esi 0x818ceca <__do_global_ctors_aux+26>: cmpl $0xffffffff,0xfffffffc(%eax) 0x818cece <__do_global_ctors_aux+30>: je 0x818cedc <__do_global_ctors_aux+44> 0x818ced0 <__do_global_ctors_aux+32>: movl (%esi),%eax 0x818ced2 <__do_global_ctors_aux+34>: call *%eax 0x818ced4 <__do_global_ctors_aux+36>: addl $0xfffffffc,%esi 0x818ced7 <__do_global_ctors_aux+39>: cmpl $0xffffffff,(%esi) 0x818ceda <__do_global_ctors_aux+42>: jne 0x818ced0 <__do_global_ctors_aux+32> 0x818cedc <__do_global_ctors_aux+44>: leal 0xfffffff8(%ebp),%esp 0x818cedf <__do_global_ctors_aux+47>: popl %ebx 0x818cee0 <__do_global_ctors_aux+48>: popl %esi 0x818cee1 <__do_global_ctors_aux+49>: leave 0x818cee2 <__do_global_ctors_aux+50>: ret 0x818cee3 <__do_global_ctors_aux+51>: nop 0x818cee4 <init_dummy>: pushl %ebp 0x818cee5 <init_dummy+1>: movl %esp,%ebp 0x818cee7 <init_dummy+3>: pushl %ebx 0x818cee8 <init_dummy+4>: call 0x818ceed <init_dummy+9> 0x818ceed <init_dummy+9>: popl %ebx 0x818ceee <init_dummy+10>: addl $0x116bb,%ebx End of assembler dump. (gdb) stepi 0x818ceb1 in __do_global_ctors_aux () (gdb) 0x818ceb3 in __do_global_ctors_aux () (gdb) 0x818ceb4 in __do_global_ctors_aux () (gdb) 0x818ceb5 in __do_global_ctors_aux () (gdb) 0x818ceba in __do_global_ctors_aux () (gdb) 0x818cebb in __do_global_ctors_aux () (gdb) 0x818cec1 in __do_global_ctors_aux () (gdb) 0x818cec7 in __do_global_ctors_aux () (gdb) 0x818ceca in __do_global_ctors_aux () (gdb) 0x818cece in __do_global_ctors_aux () (gdb) 0x818ced0 in __do_global_ctors_aux () (gdb) 0x818ced2 in __do_global_ctors_aux () (gdb) 0x0 in ?? () Program received signal SIGSEGV, Segmentation fault. 0x0 in ?? () (gdb) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-18 2:10 ` Jim Meyering @ 1998-07-17 22:28 ` Jeffrey A Law 1998-07-17 18:50 ` Jim Meyering 1998-07-17 22:28 ` David S. Miller 1998-08-16 23:08 ` Jim Meyering 1 sibling, 2 replies; 23+ messages in thread From: Jeffrey A Law @ 1998-07-17 22:28 UTC (permalink / raw) To: Jim Meyering; +Cc: David S. Miller, egcs, rms In message < 87pvf4pl6t.fsf@ascend.com >you write: > 0x0 in ?? () > (gdb) w > #0 0x0 in ?? () > #1 0x818ced4 in __do_global_ctors_aux () > #2 0x818cf15 in _init () > > But it seems crtstuff.c (__do_global_ctors_aux) can't be > compiled with -g, so here's some assembly. I'm not aware of any reason why that would be true. But anyway.... [ ... ] > stepping throught that, I made it into __register_frame_info > and back to 0x818cf05. thence into __do_global_ctors_aux: OK. > je 0x818cedc <__do_global_ctors_aux+44> > 0x818ced0 <__do_global_ctors_aux+32>: movl (%esi),%eax > 0x818ced2 <__do_global_ctors_aux+34>: call *%eax > 0x818ced4 <__do_global_ctors_aux+36>: addl $0xfffffffc,%esi > 0x818ced7 <__do_global_ctors_aux+39>: cmpl $0xffffffff,(%esi) > 0x818ceda <__do_global_ctors_aux+42>: > jne 0x818ced0 <__do_global_ctors_aux+32> The call at 0x818ced2 is jumping to location zero. Look at what's in the __CTOR_LIST__ before and after unexec; of particular interest will be the first word at that address (if nonzero, it tell the init code how many ctors to fire). The remaining entries are a list of function pointers. Based on the info I've seen I'd bet the first word is nonzero, but the second word is zero, causing __do_global_ctors_aux to jump to zero. This would most likely indicate an unexec problem of some kind. jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-17 22:28 ` Jeffrey A Law @ 1998-07-17 18:50 ` Jim Meyering 1998-07-17 22:28 ` David S. Miller 1 sibling, 0 replies; 23+ messages in thread From: Jim Meyering @ 1998-07-17 18:50 UTC (permalink / raw) To: law; +Cc: David S. Miller, egcs, rms Jeffrey A Law <law@hurl.cygnus.com> writes: | In message < 87pvf4pl6t.fsf@ascend.com >you write: | | > 0x0 in ?? () | > (gdb) w | > #0 0x0 in ?? () | > #1 0x818ced4 in __do_global_ctors_aux () | > #2 0x818cf15 in _init () | > | > But it seems crtstuff.c (__do_global_ctors_aux) can't be | > compiled with -g, so here's some assembly. | I'm not aware of any reason why that would be true. But anyway.... Oops. It was crtbegin.o (not crtstuff.c) that I couldn't build with -g. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-17 22:28 ` Jeffrey A Law 1998-07-17 18:50 ` Jim Meyering @ 1998-07-17 22:28 ` David S. Miller 1 sibling, 0 replies; 23+ messages in thread From: David S. Miller @ 1998-07-17 22:28 UTC (permalink / raw) To: law; +Cc: meyering, egcs, rms Date: Fri, 17 Jul 1998 10:14:09 -0600 From: Jeffrey A Law <law@hurl.cygnus.com> Based on the info I've seen I'd bet the first word is nonzero, but the second word is zero, causing __do_global_ctors_aux to jump to zero. This would most likely indicate an unexec problem of some kind. It could be that unexecelf is being confused by the ELF layouts which egcs produces in the executable. Essentially unexecelf just figures out the live ELF section boundaries, extends the BSS to include the lisp code loaded in, and dumps these into the resulting executable. There are two areas which might prove fruitful to investigate: 1) Do the resulting executables violate some of the assumptions about how certain text/data/bss symbols represent the boundaries of said sections? 2) Is the dwarf2 unwind info on x86 creating ELF object files which confuse unexelf in some way to output corrupt images? In any event, it appears that the bug I have seen wrt. emacs builds with egcs, and the one being seen here on x86 are two seperate bugs. This I am sure of. Later, David S. Miller davem@dm.cobaltmicro.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-18 2:10 ` Jim Meyering 1998-07-17 22:28 ` Jeffrey A Law @ 1998-08-16 23:08 ` Jim Meyering 1998-08-16 23:08 ` Jeffrey A Law 1 sibling, 1 reply; 23+ messages in thread From: Jim Meyering @ 1998-08-16 23:08 UTC (permalink / raw) To: egcs; +Cc: rms, law I regret that I haven't had time to work on this. However, I did just confirm that the problem still exists with this snapshot of the 1.1 branch from yesterday: Reading specs from /p/p/egcs-980815-08h49/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.53/specs gcc version egcs-2.91.53 19980815 (gcc2 ss-980609 experimental) I did try to build a few `cvs update -D DATE'-selected versions of egcs, but none of them bootstrapped. What version of CVS is running on Cygnus' egcs repository? Jim Meyering <meyering@ascend.com> writes: | "David S. Miller" <davem@dm.cobaltmicro.com> writes: | | | From: Jim Meyering <meyering@ascend.com> | | | | 414008 pure bytes used | | ./emacs -q -batch -f list-load-path-shadows | | make: *** [emacs] Segmentation Fault | | | | I'm pretty sure that whatever it is about egcs that provokes | | this was introduced in the first two weeks of June. The 980531 | | snapshot compiled it fine, and the first time I noticed the problem | | was about two weeks later. | | | | Thanks for the further datapoints. | | | | I am still convinced that something is going wrong with unexec when | | compiled with egcs. The evidence in your crash indicates this to me. | | | | I ask for one further experiment if you don't mind. Can you try | | compiling just unexelf.o with a working gcc, leave the rest the same | | (compiled with egcs which causes the crashes) and tell me the results. | | | | Also, it would be very useful if you could take the crashing emacs | | binary and run it under gdb, and look around for clues as to where it | | is crashing. I would not be surprised if you find it crashed | | somewhere in the middle of the solaris dynamic linker, or some place | | similar. | | I compiled unexelf.c using gcc-2.7.2.2 (with which I can build | a working emacs-20.2), and tried to rebuild. Still to no avail. | | $ gdb emacs | DISPLAY = :0.0 | TERM = xterm | Breakpoint 1 at 0x8071a90 | Breakpoint 2 at 0x80c2055: file xterm.c, line 5241. | (gdb) r -q -batch -f list-load-path-shadows | Starting program: /d/pd/emacs/stable/emacs-20.2/src/emacs -q -batch -f list-load- | path-shadows | Breakpoint 1 at 0x801f57f0 | | Program received signal SIGSEGV, Segmentation fault. | 0x0 in ?? () | (gdb) w | #0 0x0 in ?? () | #1 0x818ced4 in __do_global_ctors_aux () | #2 0x818cf15 in _init () | | But it seems crtstuff.c (__do_global_ctors_aux) can't be | compiled with -g, so here's some assembly. | | Breakpoint 3, 0x818cf00 in _init () | (gdb) disas 0x818cf00 0x818cf21 | Dump of assembler code from 0x818cf00 to 0x818cf4f: | 0x818cf00 <_init>: call 0x807309c <frame_dummy> | 0x818cf05 <_init+5>: leal 0x0(%esi,1),%esi | 0x818cf09 <_init+9>: leal 0x0(%edi,1),%edi | 0x818cf10 <_init+16>: call 0x818ceb0 <__do_global_ctors_aux> | 0x818cf15 <_init+21>: leal 0x0(%esi,1),%esi | 0x818cf19 <_init+25>: leal 0x0(%edi,1),%edi | 0x818cf20 <_init+32>: ret $0x0 | End of assembler dump. | | stepping throught that, I made it into __register_frame_info | and back to 0x818cf05. thence into __do_global_ctors_aux: | | 0x818cf10 in _init () | (gdb) | 0x818ceb0 in __do_global_ctors_aux () | (gdb) disas 0x818ceb0 0x818cef0 | Dump of assembler code from 0x818ceb0 to 0x818cef0: | 0x818ceb0 <__do_global_ctors_aux>: pushl %ebp | 0x818ceb1 <__do_global_ctors_aux+1>: movl %esp,%ebp | 0x818ceb3 <__do_global_ctors_aux+3>: pushl %esi | 0x818ceb4 <__do_global_ctors_aux+4>: pushl %ebx | 0x818ceb5 <__do_global_ctors_aux+5>: | call 0x818ceba <__do_global_ctors_aux+10> | 0x818ceba <__do_global_ctors_aux+10>: popl %ebx | 0x818cebb <__do_global_ctors_aux+11>: addl $0x116ee,%ebx | 0x818cec1 <__do_global_ctors_aux+17>: leal 0x6f688(%ebx),%eax | 0x818cec7 <__do_global_ctors_aux+23>: leal 0xfffffffc(%eax),%esi | 0x818ceca <__do_global_ctors_aux+26>: cmpl $0xffffffff,0xfffffffc(%eax) | 0x818cece <__do_global_ctors_aux+30>: | je 0x818cedc <__do_global_ctors_aux+44> | 0x818ced0 <__do_global_ctors_aux+32>: movl (%esi),%eax | 0x818ced2 <__do_global_ctors_aux+34>: call *%eax | 0x818ced4 <__do_global_ctors_aux+36>: addl $0xfffffffc,%esi | 0x818ced7 <__do_global_ctors_aux+39>: cmpl $0xffffffff,(%esi) | 0x818ceda <__do_global_ctors_aux+42>: | jne 0x818ced0 <__do_global_ctors_aux+32> | 0x818cedc <__do_global_ctors_aux+44>: leal 0xfffffff8(%ebp),%esp | 0x818cedf <__do_global_ctors_aux+47>: popl %ebx | 0x818cee0 <__do_global_ctors_aux+48>: popl %esi | 0x818cee1 <__do_global_ctors_aux+49>: leave | 0x818cee2 <__do_global_ctors_aux+50>: ret | 0x818cee3 <__do_global_ctors_aux+51>: nop | 0x818cee4 <init_dummy>: pushl %ebp | 0x818cee5 <init_dummy+1>: movl %esp,%ebp | 0x818cee7 <init_dummy+3>: pushl %ebx | 0x818cee8 <init_dummy+4>: call 0x818ceed <init_dummy+9> | 0x818ceed <init_dummy+9>: popl %ebx | 0x818ceee <init_dummy+10>: addl $0x116bb,%ebx | End of assembler dump. | (gdb) stepi | 0x818ceb1 in __do_global_ctors_aux () | (gdb) | 0x818ceb3 in __do_global_ctors_aux () | (gdb) | 0x818ceb4 in __do_global_ctors_aux () | (gdb) | 0x818ceb5 in __do_global_ctors_aux () | (gdb) | 0x818ceba in __do_global_ctors_aux () | (gdb) | 0x818cebb in __do_global_ctors_aux () | (gdb) | 0x818cec1 in __do_global_ctors_aux () | (gdb) | 0x818cec7 in __do_global_ctors_aux () | (gdb) | 0x818ceca in __do_global_ctors_aux () | (gdb) | 0x818cece in __do_global_ctors_aux () | (gdb) | 0x818ced0 in __do_global_ctors_aux () | (gdb) | 0x818ced2 in __do_global_ctors_aux () | (gdb) | 0x0 in ?? () | | Program received signal SIGSEGV, Segmentation fault. | 0x0 in ?? () | (gdb) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-08-16 23:08 ` Jim Meyering @ 1998-08-16 23:08 ` Jeffrey A Law 1998-08-17 23:32 ` Jim Meyering 0 siblings, 1 reply; 23+ messages in thread From: Jeffrey A Law @ 1998-08-16 23:08 UTC (permalink / raw) To: Jim Meyering; +Cc: egcs, rms In message < 873eawf8n0.fsf@ascend.com >you write: > I did try to build a few `cvs update -D DATE'-selected > versions of egcs, but none of them bootstrapped. What version > of CVS is running on Cygnus' egcs repository? cvs-1.9.21, but that really shouldn't have anything to do with being unable to bootstrap egcs What problems are you having bootstrapping? x86-solaris testers are few and far between. I do see that someone bootstrapped x86-solaris and ran the testsuite with the egcs-19980621 snapshot (Jorg Pietschmann <pietsch@swissline.ch>). jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-08-16 23:08 ` Jeffrey A Law @ 1998-08-17 23:32 ` Jim Meyering 1998-08-17 17:41 ` Jeffrey A Law 0 siblings, 1 reply; 23+ messages in thread From: Jim Meyering @ 1998-08-17 23:32 UTC (permalink / raw) To: law; +Cc: egcs, rms Jeffrey A Law <law@hurl.cygnus.com> writes: | In message < 873eawf8n0.fsf@ascend.com >you write: | > I did try to build a few `cvs update -D DATE'-selected | > versions of egcs, but none of them bootstrapped. What version | > of CVS is running on Cygnus' egcs repository? | cvs-1.9.21, but that really shouldn't have anything to do with being unable | to bootstrap egcs | | What problems are you having bootstrapping? Here's what I got when trying to bootstrap the official egcs-19980615 snapshot: make[1]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/libiberty' make[1]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/libiberty' make[1]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo' make all-recursive make[2]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo' Making all in intl make[3]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/intl' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/intl' Making all in lib make[3]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/lib' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/lib' Making all in makeinfo make[3]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/makeinfo' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo/makeinfo' make[2]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo' make[1]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/texinfo' Bootstrapping the compiler make[1]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/gcc' make CC="stage1/xgcc -Bstage1/" CFLAGS="-W -Wall -O2 -g -O2" LDFLAGS="" libdir=/p/p/egcs-19980615/lib STAGE_PREFIX=stage1/ LANGUAGES="c proto gcov c++ f77 objc" make[2]: Entering directory `/d/pd/gcc2/egcs-19980615/.x/gcc' stage1/xgcc -Bstage1/ -c -DIN_GCC -W -Wall -O2 -g -O2 -DHAVE_CONFIG_H -I. -I../../gcc -I../../gcc/config ../../gcc/c-lex.c ../../gcc/c-gperf.h: In function `hash': In file included from ../../gcc/c-lex.c:130: ../../gcc/c-gperf.h:43: warning: array subscript has type `char' ../../gcc/c-gperf.h:46: warning: array subscript has type `char' ../../gcc/c-gperf.h:49: warning: array subscript has type `char' ../../gcc/c-lex.c: In function `readescape': ../../gcc/c-lex.c:923: warning: comparison between signed and unsigned ../../gcc/c-lex.c: In function `yylex': ../../gcc/c-lex.c:1823: warning: comparison between signed and unsigned ../../gcc/c-lex.c:1054: warning: variable `c' might be clobbered by `longjmp' or `vfork' ../../gcc/c-lex.c:1055: warning: variable `p' might be clobbered by `longjmp' or `vfork' ../../gcc/c-lex.c:1443: warning: variable `type' might be clobbered by `longjmp' or `vfork' ../../gcc/c-lex.c:1444: warning: variable `imag' might be clobbered by `longjmp' or `vfork' ../../gcc/c-lex.c:1445: warning: variable `conversion_errno' might be clobbered by `longjmp' or `vfork' ../../gcc/global.c:401: Internal compiler error in function global_alloc make[2]: *** [c-lex.o] Error 1 make[2]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/gcc' make[1]: *** [bootstrap2] Error 2 make[1]: Leaving directory `/d/pd/gcc2/egcs-19980615/.x/gcc' make: *** [bootstrap2] Error 2 | x86-solaris testers are few and far between. I do see that someone | bootstrapped x86-solaris and ran the testsuite with the egcs-19980621 | snapshot (Jorg Pietschmann <pietsch@swissline.ch>). | | jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-08-17 23:32 ` Jim Meyering @ 1998-08-17 17:41 ` Jeffrey A Law 1998-08-17 22:15 ` Jim Meyering 1998-08-17 22:15 ` Jim Meyering 0 siblings, 2 replies; 23+ messages in thread From: Jeffrey A Law @ 1998-08-17 17:41 UTC (permalink / raw) To: Jim Meyering; +Cc: egcs, rms In message < 87yasnenke.fsf@ascend.com >you write: > Jeffrey A Law <law@hurl.cygnus.com> writes: > > | In message < 873eawf8n0.fsf@ascend.com >you write: > | > I did try to build a few `cvs update -D DATE'-selected > | > versions of egcs, but none of them bootstrapped. What version > | > of CVS is running on Cygnus' egcs repository? > | cvs-1.9.21, but that really shouldn't have anything to do with being unab > le > | to bootstrap egcs > | > | What problems are you having bootstrapping? > > Here's what I got when trying to bootstrap the official egcs-19980615 > snapshot: [ ... ] OK. This has nothing to do with whatever cvs version we're running. It sounds more like the typical development instability. What happens if you try to build something newer, paricularly off the egcs-1.1 branch? jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-08-17 17:41 ` Jeffrey A Law @ 1998-08-17 22:15 ` Jim Meyering 1998-08-17 22:15 ` Jim Meyering 1 sibling, 0 replies; 23+ messages in thread From: Jim Meyering @ 1998-08-17 22:15 UTC (permalink / raw) To: law; +Cc: egcs, rms | In message < 87yasnenke.fsf@ascend.com >you write: | > Jeffrey A Law <law@hurl.cygnus.com> writes: | > | > | In message < 873eawf8n0.fsf@ascend.com >you write: | > | > I did try to build a few `cvs update -D DATE'-selected | > | > versions of egcs, but none of them bootstrapped. What version | > | > of CVS is running on Cygnus' egcs repository? | > | cvs-1.9.21, but that really shouldn't have anything to do with being unab | > le | > | to bootstrap egcs | > | | > | What problems are you having bootstrapping? | > | > Here's what I got when trying to bootstrap the official egcs-19980615 | > snapshot: | [ ... ] | OK. This has nothing to do with whatever cvs version we're running. It | sounds more like the typical development instability. What happens if | you try to build something newer, paricularly off the egcs-1.1 branch? | jeff Whoops. I misunderstood. I have *not* been doing `cvs update -DDATE' for a month. I'm convinced that it's just instability as you say. The problem is that I didn't have time to find out which subsequent patch fixed the bootstrap problem I saw when trying to localize the emacs-build-breaking change. Unfortunately, I don't expect to have much time to work on this for the next week or so -- I'll be offline from Thur through Mon. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-08-17 17:41 ` Jeffrey A Law 1998-08-17 22:15 ` Jim Meyering @ 1998-08-17 22:15 ` Jim Meyering 1998-08-17 19:53 ` Jeffrey A Law 1 sibling, 1 reply; 23+ messages in thread From: Jim Meyering @ 1998-08-17 22:15 UTC (permalink / raw) To: law; +Cc: egcs, rms | In message < 87yasnenke.fsf@ascend.com >you write: | > Jeffrey A Law <law@hurl.cygnus.com> writes: | > | > | In message < 873eawf8n0.fsf@ascend.com >you write: | > | > I did try to build a few `cvs update -D DATE'-selected | > | > versions of egcs, but none of them bootstrapped. What version | > | > of CVS is running on Cygnus' egcs repository? | > | cvs-1.9.21, but that really shouldn't have anything to do with being unab | > le | > | to bootstrap egcs | > | | > | What problems are you having bootstrapping? | > | > Here's what I got when trying to bootstrap the official egcs-19980615 | > snapshot: | [ ... ] | OK. This has nothing to do with whatever cvs version we're running. It | sounds more like the typical development instability. What happens if | you try to build something newer, paricularly off the egcs-1.1 branch? I've been doing that (with the trunk, then, since the branch, with 1.1) for more than a month. It works fine. Of course, using the resulting compiler to try to build emacs is what fails. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-08-17 22:15 ` Jim Meyering @ 1998-08-17 19:53 ` Jeffrey A Law 1998-08-17 22:15 ` Jim Meyering 0 siblings, 1 reply; 23+ messages in thread From: Jeffrey A Law @ 1998-08-17 19:53 UTC (permalink / raw) To: Jim Meyering; +Cc: egcs, rms In message < 87iujrs9ax.fsf@ascend.com >you write: > | OK. This has nothing to do with whatever cvs version we're running. It > | sounds more like the typical development instability. What happens if > | you try to build something newer, paricularly off the egcs-1.1 branch? > > I've been doing that (with the trunk, then, since the branch, with 1.1) > for more than a month. It works fine. Of course, using the resulting > compiler to try to build emacs is what fails. I'm really confused -- look back at what you said a little while ago: | > | In message < 873eawf8n0.fsf@ascend.com >you write: | > | > I did try to build a few `cvs update -D DATE'-selected | > | > versions of egcs, but none of them bootstrapped. What version | > | > of CVS is running on Cygnus' egcs repository? So in fact, you can bootstrap, but we still have problems with XEmacs right? jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-08-17 19:53 ` Jeffrey A Law @ 1998-08-17 22:15 ` Jim Meyering 1998-08-19 0:29 ` Jeffrey A Law 0 siblings, 1 reply; 23+ messages in thread From: Jim Meyering @ 1998-08-17 22:15 UTC (permalink / raw) To: law; +Cc: egcs, rms | In message < 87iujrs9ax.fsf@ascend.com >you write: | > | OK. This has nothing to do with whatever cvs version we're running. It | > | sounds more like the typical development instability. What happens if | > | you try to build something newer, paricularly off the egcs-1.1 branch? | > | > I've been doing that (with the trunk, then, since the branch, with 1.1) | > for more than a month. It works fine. Of course, using the resulting | > compiler to try to build emacs is what fails. | I'm really confused -- look back at what you said a little while ago: | | | > | In message < 873eawf8n0.fsf@ascend.com >you write: | | > | > I did try to build a few `cvs update -D DATE'-selected | | > | > versions of egcs, but none of them bootstrapped. What version | | > | > of CVS is running on Cygnus' egcs repository? | | So in fact, you can bootstrap, but we still have problems with XEmacs right? *X*Emacs? could you be thinking of something different? I saw a thread about an abort with XEmacs. This is a segfault that happens during the make process for *FSF* emacs-20.2 (and 20.2.99) when the just-created emacs executable is run like this: ../src/emacs -batch --no-init-file --no-site-file --multibyte ... I bootstrapped the head of egcs-1.1 after the last change and installed it. I cannot build a working FSF emacs 20.2 using that compiler. Reading specs from \ /p/p/egcs-980817-00h35/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.54/specs gcc version egcs-2.91.54 19980816 (gcc2 ss-980609 experimental) Note that compiling and linking go just fine. David Miller hypothesized that the failure is related to the unexec. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-08-17 22:15 ` Jim Meyering @ 1998-08-19 0:29 ` Jeffrey A Law 0 siblings, 0 replies; 23+ messages in thread From: Jeffrey A Law @ 1998-08-19 0:29 UTC (permalink / raw) To: Jim Meyering; +Cc: egcs, rms In message < 87af53s88r.fsf@ascend.com >you write: > *X*Emacs? could you be thinking of something different? I saw a thread > about an abort with XEmacs. This is a segfault that happens during the > make process for *FSF* emacs-20.2 (and 20.2.99) when the just-created > emacs executable is run like this: Sorry. A thinko/typo on my part. > ../src/emacs -batch --no-init-file --no-site-file --multibyte ... > > I bootstrapped the head of egcs-1.1 after the last change and installed it. > I cannot build a working FSF emacs 20.2 using that compiler. > > Reading specs from \ > /p/p/egcs-980817-00h35/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.91.54/sp > ecs > gcc version egcs-2.91.54 19980816 (gcc2 ss-980609 experimental) > > Note that compiling and linking go just fine. > David Miller hypothesized that the failure is related to the unexec. Right. And more specifically you're calling to location zero out of do_global_something. So I think you need to look at the global ctor/dtor lists before and after the unexec to see if they make sense. jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-16 5:38 ` David S. Miller 1998-07-17 0:00 ` David S. Miller @ 1998-07-17 1:02 ` Horst von Brand 1 sibling, 0 replies; 23+ messages in thread From: Horst von Brand @ 1998-07-17 1:02 UTC (permalink / raw) To: David S. Miller; +Cc: meyering, egcs, law, rms [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 967 bytes --] "David S. Miller" <davem@dm.cobaltmicro.com> said: > Jim Meyering <meyering@ascend.com> said: > Has anyone built a recent version of emacs (20.2 or newer test > releases) with an egcs snapshot from June or later? > I did some research into this and I have an emacs tree which reliably > reproduces the problem you are seeing, but for me on sparc-linux > targets. My emacs-20.2 (stock GNU source) was compiled with egcs: GNU Emacs 20.2.1 (i586-redhat-linux-gnu, X toolkit) of Mon Jul 6 1998 on sleipnir Must have been egcs-19980628, -O2 -fomit-frame-pointer -march=pentium. Note I'm using a (somewhat patched) glibc-2.0.94, binutils-2.9.1.0.6 at the time. Works fine. No idea if this is in any way relevant... Will try and see what the latest egcs gives on sparc-sun-solaris2.5.1 if time allows. -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 1998-07-15 0:54 ` Jim Meyering ` (2 preceding siblings ...) 1998-07-16 5:38 ` David S. Miller @ 1998-07-17 18:50 ` Jim Meyering 3 siblings, 0 replies; 23+ messages in thread From: Jim Meyering @ 1998-07-17 18:50 UTC (permalink / raw) To: egcs; +Cc: Jeffrey A Law, David S. Miller | I wrote: | | I can build emacs-20.2 using egcs-980531, but more recent snapshots | | (starting a week or two ago) can no longer build it. Here's the | | failure I get using a recent snapshot (I updated last night): I just built emacs-20.2 using the egcs-19980608 snapshot. So now, I think it was a change made in the week or 10 days following the June 8 snapshot. The 0615 snapshot didn't bootstrap -- more later. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~1998-08-19 0:29 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-06-20 13:06 i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2 Jim Meyering 1998-07-15 0:54 ` Jim Meyering 1998-07-15 16:08 ` Dave Love 1998-07-16 0:32 ` Jeffrey A Law 1998-07-16 5:38 ` David S. Miller 1998-07-17 0:00 ` David S. Miller 1998-07-17 8:59 ` Jim Meyering 1998-07-17 8:59 ` David S. Miller 1998-07-18 2:10 ` Jim Meyering 1998-07-17 22:28 ` Jeffrey A Law 1998-07-17 18:50 ` Jim Meyering 1998-07-17 22:28 ` David S. Miller 1998-08-16 23:08 ` Jim Meyering 1998-08-16 23:08 ` Jeffrey A Law 1998-08-17 23:32 ` Jim Meyering 1998-08-17 17:41 ` Jeffrey A Law 1998-08-17 22:15 ` Jim Meyering 1998-08-17 22:15 ` Jim Meyering 1998-08-17 19:53 ` Jeffrey A Law 1998-08-17 22:15 ` Jim Meyering 1998-08-19 0:29 ` Jeffrey A Law 1998-07-17 1:02 ` Horst von Brand 1998-07-17 18:50 ` Jim Meyering
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).