This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2
- To: meyering at ascend dot com
- Subject: Re: i386-pc-solaris2.5.1: recent snapshots can't build emacs-20.2
- From: "David S. Miller" <davem at dm dot cobaltmicro dot com>
- Date: Thu, 16 Jul 1998 05:36:32 -0700
- CC: egcs at cygnus dot com, law at cygnus dot com, rms at gnu dot org
- References: <87ogvnvnxi.fsf@eng.ascend.com> <87sok3zs6t.fsf@eng.ascend.com>
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