[Bug optimization/11386] GNU Emacs 21.3 failed to install using GCC 3.3, but GCC 3.2.3 works.

[ishikawa at yk dot rim dot or dot jp]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386



------- Additional Comments From ishikawa at yk dot rim dot or dot jp  2003-07-14 23:32 -------
Too bad.

If this is the case, then I think there is a documentation bug
somewhere in that this command line option information is not easy to
retrieve from the end user perspective.  I coud not find it in my copy
of document files in GCC 3.3 branch CVS.  (Or is it in the latest GNU
Emacs CVS? I have not checked with Emacs CVS since ordinary users
will use released Emacs 21.3 and released GCC 3.3.)

>From the end user's perspective, this is what happens.

 GCC 3.2.3 and GNU Emacs 21.3 worked.
 GCC 3.3   and GNU Emacs 21.3 doesn't work under UltraSparc solaris 8.

Many are likely to turn to GCC 3.3 documentation sources since
GCC version is the variable here that seems to trigger the
problem.

So GCC 3.3 doc should contain a clear message on this problem IMHO.

OK, this is what I found in gcc.info after doing
 find ... -type f -print | xargs egrep -i emacs
 find ... -type f -print | xargs egrep -i zero-initialized-in-bss

>`-fno-zero-initialized-in-bss'
>     If the target supports a BSS section, GCC by default puts
>     variables that are initialized to zero into BSS.  This can save
>     space in the resulting code.
>
>     This option turns off this behavior because some programs
>     explicitly rely on variables going to the data section.  E.g., so
>     that the resulting executable can find the beginning of that
>     section and/or make assumptions based on that.
>
>     The default is `-fzero-initialized-in-bss'.

Why don't we explicitly say "some programs, notably GNU Emacs 21.3 and
prior versions, explicitly rely on ... " here?

In the meantime, for those who failed to obtain the info on this new
command line option (and it is not only me AFAIK), there were fixes on
the Emacs side.

Here is a summary of what I found out. I thought we should put
this info to make this bugzilla entry complete.

The problem was two-fold.

Basically, GNU Emacs assumes certain memory layout assumptions which
were broken due to the facts that GCC 3.3  put zero-initialized data into
.bss segument rather than into .data segument by default.
(This behavior seems to be changeable by the GCC command line option as
Eric pointed out.)

Also, a subtle change in the binary output also
misled the undump() in unexelf.c.

Both of these problems are handled by the Emacs source file patches which
Paul Eggert posted to emacs-pretest mailing list.

See the patches in the following posts.

http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00207.html

http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00219.html


A few people including me reported successful compilation and
installation of Emacs 21.3 under UltraSparc  Solaris 8
using the patches to Emacs 21.3.
(The problem with unexec() is very sensitive
with memory layout of binary segments and it seems why
Eric's patch to an Emacs file is ineffective to others
and unexelf.c patch was necessary after all.)

One of the posts generated a GCC warning and Paul mentioned that the
following patch fixed the warning problem.

(From 
http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00268.html

>> Date: Mon, 14 Jul 2003 12:19:12 +0100
>> 
>> alloc.c:398: warning: initialization makes pointer from integer without
>> a cast
>
>Yes, thanks: I fixed that by using the following instead in the
>version that I checked into the Emacs trunk:
>
>Lisp_Object *staticvec[NSTATICS] = {&Vpurify_flag};

So if future Emacs 21.3 users (with GCC 3.3) don't realize
the -fno-zero-initialized-in-bss option, Emacs is likely
to be successfully installed with GCC 3.3.

Hope this helps.

I understand that maintaining a large complex software like GCC
and GNU Emacs requires care and on-going effrots to improve and
debug problems along the way.
Also, technology transfer in the sense of educating users
takes time. (And writing documentation takes time, too.)

I would like to thank people who has made GCC accessible
as free software as it is now.

Happy Hacking,