* Anyone built Emacs with gcc-3.3?
@ 2003-07-04 8:33 Marshall, Simon
2003-07-04 8:41 ` Dhruva Krishnamurthy
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Marshall, Simon @ 2003-07-04 8:33 UTC (permalink / raw
I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on solaris-2.8
but without success. Emacs builds but coredumps on exit, see bug #11386
at GCC Bugzilla via http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.
Have any of you guys built with gcc-3.3 or any snapshot prior to its
release? I ask because the bug looks like it might be tricky to track
down; the gcc guy dealing with it wants a lot more input; it's not clear
whether it is platform-dependent (the guy who got around to reporting it
before me is also on solaris-2.8).
Simon.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-04 8:33 Marshall, Simon
@ 2003-07-04 8:41 ` Dhruva Krishnamurthy
2003-07-04 16:17 ` puneet
` (2 subsequent siblings)
3 siblings, 0 replies; 27+ messages in thread
From: Dhruva Krishnamurthy @ 2003-07-04 8:41 UTC (permalink / raw
On Fri, 4 Jul 2003 09:33:49 +0100 , "Marshall, Simon"
<simon.marshall@misys.com> said:
> I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on solaris-2.8
> but without success. Emacs builds but coredumps on exit, see bug #11386
> at GCC Bugzilla via http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.
>
> Have any of you guys built with gcc-3.3 or any snapshot prior to its
> release? I ask because the bug looks like it might be tricky to track
> down; the gcc guy dealing with it wants a lot more input; it's not clear
> whether it is platform-dependent (the guy who got around to reporting it
> before me is also on solaris-2.8).
>
> Simon.
I had rised a similar BUG on W2K and Wolfgang Bangerth from GCC
responded. I did not have any other way to nail the cause, hence I gace
up.
Refer bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9816
with regards,
dhruva
--
Dhruva Krishnamurthy
Home: http://www32.brinkster.com/schemer/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
@ 2003-07-04 12:36 Nelson H. F. Beebe
0 siblings, 0 replies; 27+ messages in thread
From: Nelson H. F. Beebe @ 2003-07-04 12:36 UTC (permalink / raw
Cc: beebe
If any of you have an earlier version of gcc still installed after
installing gcc-3.3 (I kept 2.95.3 around), I suggest that you try to
debug the core dump problem by successively recompiling one file at a
time with the older gcc. This can be automated with a modest script,
and I've found it a useful technique in the past to deal with compiler
errors in large programs.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- Center for Scientific Computing FAX: +1 801 581 4148 -
- University of Utah Internet e-mail: beebe@math.utah.edu -
- Department of Mathematics, 110 LCB beebe@acm.org beebe@computer.org -
- 155 S 1400 E RM 233 beebe@ieee.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- Center for Scientific Computing FAX: +1 801 581 4148 -
- University of Utah Internet e-mail: beebe@math.utah.edu -
- Department of Mathematics, 110 LCB beebe@acm.org beebe@computer.org -
- 155 S 1400 E RM 233 beebe@ieee.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-04 8:33 Marshall, Simon
2003-07-04 8:41 ` Dhruva Krishnamurthy
@ 2003-07-04 16:17 ` puneet
2003-07-08 22:41 ` Dave Love
2003-07-05 22:25 ` Richard Stallman
2003-07-08 22:30 ` Dave Love
3 siblings, 1 reply; 27+ messages in thread
From: puneet @ 2003-07-04 16:17 UTC (permalink / raw
Cc: 'Emacs Developers'
I am using emacs on solaris 2.8. Right now I am using emacs from
CVS. Earlier on I had emacs 21.3 compiled with 64-bit gcc 3.3. And it
did not give any problems.
I have compiled emacs in gcc 3.3. Actually I configured gcc for
sparcv9 arch. And hence my emacs is 64-bit. I use it daily. I believe
I used gcc 3.3 only to install emacs as my emacs was installed later
than I installed the present gcc.
I will try compiling emacs with 32 bit gcc early next week, as I do
not have access to my solaris system at home.
Regards
- puneet
(emacs-version)
"GNU Emacs 21.3.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars)
of 2003-06-27 on cheetah"
$ uname -a
SunOS cheetah 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-60 Solaris
$ file `which emacs`
/home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/emacs: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), dynamically linked (uses shared libs), stripped
$ gcc -v
Reading specs from /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/gcc-lib/sparcv9-sun-solaris2.8/3.3/specs
Configured with: ../gcc-3.3/configure --disable-nls --enable-threads --enable-languages=c,c++,f77 --prefix=/home/pgoel/local/gnu --exec-prefix=${prefix}/arch/sparcv9-sun-solaris2.8 --host=sparcv9-sun-solaris2.8
Thread model: posix
gcc version 3.3
$ ls -la `which gcc`
-r-xr-xr-x 3 pgoel staff 123608 2003-05-16 01:13 /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/gcc
$ which emacs
/home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/emacs
$ ls -la `which emacs`
-r-xr-xr-x 2 pgoel staff 12604912 2003-06-27 03:53 /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/emacs
>>>>> "Marshall" == Marshall, Simon <simon.marshall@misys.com> writes:
Marshall> I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3
Marshall> on solaris-2.8 but without success. Emacs builds but
Marshall> coredumps on exit, see bug #11386 at GCC Bugzilla via
Marshall> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.
Marshall> Have any of you guys built with gcc-3.3 or any snapshot
Marshall> prior to its release? I ask because the bug looks like
Marshall> it might be tricky to track down; the gcc guy dealing
Marshall> with it wants a lot more input; it's not clear whether
Marshall> it is platform-dependent (the guy who got around to
Marshall> reporting it before me is also on solaris-2.8).
Marshall> Simon.
Marshall> --
--
--
Puneet Goel
--
BLESSED is he whose fame does not
outshine his truth.
-
Stray Birds, Rabindernath Tagore
--
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-04 8:33 Marshall, Simon
2003-07-04 8:41 ` Dhruva Krishnamurthy
2003-07-04 16:17 ` puneet
@ 2003-07-05 22:25 ` Richard Stallman
2003-07-11 9:55 ` Paul Eggert
2003-07-08 22:30 ` Dave Love
3 siblings, 1 reply; 27+ messages in thread
From: Richard Stallman @ 2003-07-05 22:25 UTC (permalink / raw
Cc: emacs-devel
I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on solaris-2.8
but without success.
Does it work with other GCC versions?
Emacs builds but coredumps on exit, see bug #11386
at GCC Bugzilla via http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.
Do you mean it core dumps when you type C-c C-c?
The way to debug this is to treat it as an Emacs bug. When you
find the bug, it will actually be a miscompiled function (if this
is GCC's fault). Then you can send a useful GCC bug report.
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: Anyone built Emacs with gcc-3.3?
@ 2003-07-07 8:26 Marshall, Simon
2003-07-08 14:28 ` Richard Stallman
0 siblings, 1 reply; 27+ messages in thread
From: Marshall, Simon @ 2003-07-07 8:26 UTC (permalink / raw
Cc: emacs-devel
Yes, Emacs works with 3.2.3. With 3.3 it dumps core on C-x C-c in
__do_global_dtors_aux() after Fkill_emacs() calls exit().
-----Original Message-----
From: Richard Stallman [mailto:rms@gnu.org]
Sent: 05 July 2003 23:26
To: Marshall, Simon
Cc: emacs-devel@gnu.org; emacs-pretesters@gnu.org
Subject: Re: Anyone built Emacs with gcc-3.3?
I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on
solaris-2.8
but without success.
Does it work with other GCC versions?
Emacs builds but coredumps on exit, see bug
#11386
at GCC Bugzilla via
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.
Do you mean it core dumps when you type C-c C-c?
The way to debug this is to treat it as an Emacs bug. When you
find the bug, it will actually be a miscompiled function (if this
is GCC's fault). Then you can send a useful GCC bug report.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-07 8:26 Anyone built Emacs with gcc-3.3? Marshall, Simon
@ 2003-07-08 14:28 ` Richard Stallman
2003-07-08 14:39 ` Jason Rumney
0 siblings, 1 reply; 27+ messages in thread
From: Richard Stallman @ 2003-07-08 14:28 UTC (permalink / raw
Cc: emacs-devel
Yes, Emacs works with 3.2.3. With 3.3 it dumps core on C-x C-c in
__do_global_dtors_aux() after Fkill_emacs() calls exit().
I have a hunch that relates to unexec. Perhaps unexec fails to
preserve some of the data that __do_global_dtors_aux uses.
Debugging the details is the only way to proceed.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-08 14:28 ` Richard Stallman
@ 2003-07-08 14:39 ` Jason Rumney
2003-07-09 5:34 ` Dhruva Krishnamurthy
0 siblings, 1 reply; 27+ messages in thread
From: Jason Rumney @ 2003-07-08 14:39 UTC (permalink / raw
Cc: emacs-devel
Richard Stallman wrote:
> Yes, Emacs works with 3.2.3. With 3.3 it dumps core on C-x C-c in
> __do_global_dtors_aux() after Fkill_emacs() calls exit().
>
> I have a hunch that relates to unexec. Perhaps unexec fails to
> preserve some of the data that __do_global_dtors_aux uses.
>
> Debugging the details is the only way to proceed.
Someone else reported yesterday that a recent version of ld from
binutils has changed the position of some of the data segments in ELF
executables, causing problems with unexec. I think it is worth
investigating if this is really the cause of the gcc 3.3 problems, as it
could save a lot of debugging.
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: Anyone built Emacs with gcc-3.3?
@ 2003-07-08 15:18 Marshall, Simon
2003-07-09 15:49 ` Richard Stallman
2003-07-11 9:57 ` Paul Eggert
0 siblings, 2 replies; 27+ messages in thread
From: Marshall, Simon @ 2003-07-08 15:18 UTC (permalink / raw
Cc: emacs-devel
> > Yes, Emacs works with 3.2.3. With 3.3 it dumps core on
> C-x C-c in
> > __do_global_dtors_aux() after Fkill_emacs() calls exit().
> >
> > I have a hunch that relates to unexec. Perhaps unexec fails to
> > preserve some of the data that __do_global_dtors_aux uses.
> >
> > Debugging the details is the only way to proceed.
The guys who first raised it on bugzilla had the same hunch. The
problem is: where do I start? I can't debug in __do_global_dtors_aux()
as there is no debugging info. Do I have to build libgcc.a with
debugging (or whatever it is that supplied __do_global_dtors_aux())?
> Someone else reported yesterday that a recent version of ld from
> binutils has changed the position of some of the data segments in ELF
> executables, causing problems with unexec. I think it is worth
> investigating if this is really the cause of the gcc 3.3
> problems, as it
> could save a lot of debugging.
Thanks, though in my case I am using Sun as & ld (unless gcc comes with
a binutils ld and is quietly using it).
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-04 8:33 Marshall, Simon
` (2 preceding siblings ...)
2003-07-05 22:25 ` Richard Stallman
@ 2003-07-08 22:30 ` Dave Love
3 siblings, 0 replies; 27+ messages in thread
From: Dave Love @ 2003-07-08 22:30 UTC (permalink / raw
Cc: 'Emacs Pretesters', 'Emacs Developers'
"Marshall, Simon" <simon.marshall@misys.com> writes:
> I've tried to build emacs-21.3 and 21.1.90 with gcc-3.3 on solaris-2.8
> but without success. Emacs builds but coredumps on exit, see bug #11386
> at GCC Bugzilla via http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386.
That suggests it is dependent on data size. I've seen similar
behaviour on Tru64 which was related to the use of mmap if I remember
correctly and never got resolved. Also if I remember correctly, handa
had a similar problem on Solaris and resolved it on the basis of what
I said about the Tru64 problem, but I don't recall how.
For what it's worth, Emacs 21.3 appears to work on sparc64 with the
gcc pre-3.3.1 in Debian testing.
unexec problems are likely with a new gcc on ELF platforms. To
investigate, I would run objdump or elfdump (?) on temacs versions
that work and don't work, looking for unexpected sections. (You want
whatever option lists all the section headers.) That might suggest
other things that need to be copied, for instance. [In case that
turns out to be the case, let me say again that undumping should be
dumped.]
At one time, building Emacs was part of the regression testing for
gcc. If that's been dropped, it seems like a backward move.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-04 16:17 ` puneet
@ 2003-07-08 22:41 ` Dave Love
2003-07-09 12:31 ` Puneet Goel
0 siblings, 1 reply; 27+ messages in thread
From: Dave Love @ 2003-07-08 22:41 UTC (permalink / raw
Cc: Marshall, Simon, 'Emacs Pretesters',
'Emacs Developers'
puneet <puneet@computer.org> writes:
> I have compiled emacs in gcc 3.3. Actually I configured gcc for
> sparcv9 arch. And hence my emacs is 64-bit.
That doesn't follow. -mcpu=v9 is orthogonal to -m64. `file' will
tell you whether the binary is 64-bit, but as far as I remember, you
won't get 64-bit Emacs words with gcc anyhow since gcc doesn't define
_LP64. (gcc -m64 wasn't useful when I last touched 64-bit sparc
configuration.) Somewhere I have some changes to somewhat sanitize
64-bit configuration, but as far as I know there are still some basic
problems with 64-bit systems, especially big-endian ones, and I'm
surprised they work at all...
If it behaves differently on different Solaris systems with the same
OS version then you should probably look at all the installed patches,
versions of development tools (I assume you use the Sun ld) and what
you pick up from the system libraries -- the version of malloc in
particular.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-08 14:39 ` Jason Rumney
@ 2003-07-09 5:34 ` Dhruva Krishnamurthy
2003-07-09 7:36 ` Pascal Obry
2003-07-09 7:59 ` Jason Rumney
0 siblings, 2 replies; 27+ messages in thread
From: Dhruva Krishnamurthy @ 2003-07-09 5:34 UTC (permalink / raw
Cc: Marshall, Simon, Emacs Beta, Emacs Devel
On Tue, 08 Jul 2003 15:39:47 +0100, "Jason Rumney" <jasonr@gnu.org> said:
> Richard Stallman wrote:
>
> > Yes, Emacs works with 3.2.3. With 3.3 it dumps core on C-x C-c in
> > __do_global_dtors_aux() after Fkill_emacs() calls exit().
> >
> > I have a hunch that relates to unexec. Perhaps unexec fails to
> > preserve some of the data that __do_global_dtors_aux uses.
> >
> > Debugging the details is the only way to proceed.
>
> Someone else reported yesterday that a recent version of ld from
> binutils has changed the position of some of the data segments in ELF
> executables, causing problems with unexec. I think it is worth
> investigating if this is really the cause of the gcc 3.3 problems, as it
> could save a lot of debugging.
>
I had sent an email to the list:
----------------------------------------------------------------------------------------------
I had tried building GNU Emacs with GCC 3.3 and had encountered a
problem which I have raised as a bug in GCC bugzilla(#9816).
I tried again using a newer port of GCC 3.3 and GCC 3.4 (not an official
port though) from:
http://www.thisiscool.com/gcc33_mingw.htm
I am unable to build or even progress to get an emacs.exe (executable).
With the earlier port of GCC 3.3, I could build a bare emacs executable
which failed in compiling elisp files.
If someone has a link to a GCC 3.3 port on W2K (Win32/MinGW), please let
me know. I will try to do some extensive testing. Unfortunately, I do not
have the older GCC 3.3 port with me now!
----------------------------------------------------------------------------------------------
As the problem is happening on Windows 2000 (W2K) platform, I feel it is
not releted to
unexec and specific to ELF. On W2K, I am not sure it uses 'ld' for
linking. So, modifications to 'ld' may not be the cause.
with regards,
dhruva
--
Dhruva Krishnamurthy
Web: http://schemer.fateback.com/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-09 5:34 ` Dhruva Krishnamurthy
@ 2003-07-09 7:36 ` Pascal Obry
2003-07-09 7:59 ` Jason Rumney
1 sibling, 0 replies; 27+ messages in thread
From: Pascal Obry @ 2003-07-09 7:36 UTC (permalink / raw
Cc: Emacs Beta, Marshall, Simon, Emacs Devel, Richard Stallman
Dhruva,
> I had sent an email to the list:
> ----------------------------------------------------------------------------------------------
> I had tried building GNU Emacs with GCC 3.3 and had encountered a
> problem which I have raised as a bug in GCC bugzilla(#9816).
> I tried again using a newer port of GCC 3.3 and GCC 3.4 (not an official
> port though) from:
> http://www.thisiscool.com/gcc33_mingw.htm
>
> I am unable to build or even progress to get an emacs.exe (executable).
> With the earlier port of GCC 3.3, I could build a bare emacs executable
> which failed in compiling elisp files.
> If someone has a link to a GCC 3.3 port on W2K (Win32/MinGW), please let
> me know. I will try to do some extensive testing. Unfortunately, I do not
> have the older GCC 3.3 port with me now!
> ----------------------------------------------------------------------------------------------
> As the problem is happening on Windows 2000 (W2K) platform, I feel it is
> not releted to
> unexec and specific to ELF. On W2K, I am not sure it uses 'ld' for
> linking. So, modifications to 'ld' may not be the cause.
'ld' is used on Windows.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-09 5:34 ` Dhruva Krishnamurthy
2003-07-09 7:36 ` Pascal Obry
@ 2003-07-09 7:59 ` Jason Rumney
1 sibling, 0 replies; 27+ messages in thread
From: Jason Rumney @ 2003-07-09 7:59 UTC (permalink / raw
Cc: Emacs Devel
"Dhruva Krishnamurthy" <seagull@fastmail.fm> writes:
> As the problem is happening on Windows 2000 (W2K) platform, I feel it is
> not releted to unexec and specific to ELF.
Right.
> On W2K, I am not sure it uses 'ld' for linking.
If gcc is used for compiling, then ld is used for linking. But the
executable format is COFF on Windows IIRC, not ELF.
> So, modifications to 'ld' may not be the cause.
Maybe, but since the problem with ld has already been proven, perhaps
we should fix that first, and see if it makes a difference.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-08 22:41 ` Dave Love
@ 2003-07-09 12:31 ` Puneet Goel
2003-07-15 22:31 ` Dave Love
0 siblings, 1 reply; 27+ messages in thread
From: Puneet Goel @ 2003-07-09 12:31 UTC (permalink / raw
Cc: 'Emacs Pretesters', Marshall, Simon,
'Emacs Developers', puneet
>>>>> "Dave" == Dave Love <d.love@dl.ac.uk> writes:
Dave> puneet <puneet@computer.org> writes:
>> I have compiled emacs in gcc 3.3. Actually I configured gcc for
>> sparcv9 arch. And hence my emacs is 64-bit.
Dave> That doesn't follow. -mcpu=v9 is orthogonal to -m64.
Sorry, I did not know that. For record, I am not a software
engineer. I am a hardware professional. And I needed 64-bit emacs
to read big files. I do use gcc -m64 for building my emacs. I try
building 64-bit emacs from emacs CVS almost once a week. Never
faced a problem.
I think I first successfully built 64-bit emacs some three months
back. That was the time when our sys-admin upgraded my sparc
machine to solaris 2.8. Our sys-admin is on leave, and I do not
know a way to get patch information on my system. I believe he
installed just the recommended patches from Sun.
So I have been compiling and running 64-bit emacs versions 21.X
and 21.3.50 on my solaris 2.8 for the past three months now
without any issue. The only issue I face is when I set my display
to a linux system, and launch 64-bit emacs on that display, emacs
dumps core. 32-bit solaris emacs compiles work fine.
I am sure that my emacs is 64-bit because ....
1. I use gcc -m64 to compile that.
2. I am able to open BIG files (200MB and more) with this
emacs. 32-bit emacs gives "Maximum buffer size exceeded" for
the same files.
3. I had to compile 64-bit versions of all the required
libraries. And my emacs is linked to 64-bit versions of sun
libraries. here is the ldd output ....
$ ldd /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/bin/emacs
libXaw3d.so.5 => /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libXaw3d.so.5
libXmu.so.4 => /usr/lib/64/libXmu.so.4
libXt.so.4 => /usr/lib/64/libXt.so.4
libSM.so.6 => /usr/lib/64/libSM.so.6
libICE.so.6 => /usr/lib/64/libICE.so.6
libXext.so.0 => /usr/lib/64/libXext.so.0
libtiff.so => /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libtiff.so
libjpeg.so.62 => /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libjpeg.so.62
libpng.so.3 => /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libpng.so.3
libz.so => /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libz.so
libm.so.1 => /usr/lib/64/libm.so.1
libungif.so.4 => /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libungif.so.4
libXpm.so.4.11 => /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/libXpm.so.4.11
libX11.so.4 => /usr/lib/64/libX11.so.4
libsocket.so.1 => /usr/lib/64/libsocket.so.1
libnsl.so.1 => /usr/lib/64/libnsl.so.1
libkstat.so.1 => /usr/lib/64/libkstat.so.1
libcurses.so.1 => /usr/lib/64/libcurses.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libICE.so.6 (SUNWprivate) => (version not found)
libICE.so.6 (SUNWprivate) => (version not found)
libdl.so.1 => /usr/lib/64/libdl.so.1
libdga.so.1 => /usr/openwin/lib/sparcv9/libdga.so.1
libgcc_s.so.1 => /home/pgoel/local/gnu/arch/sparcv9-sun-solaris2.8/lib/sparcv9/libgcc_s.so.1
libmp.so.2 => /usr/lib/64/libmp.so.2
/usr/platform/SUNW,Ultra-60/lib/sparcv9/libc_psr.so.1
Dave>
Dave> `file' will tell you whether the binary is 64-bit, but as
Dave> far as I remember, you won't get 64-bit Emacs words with gcc
Dave> anyhow since gcc doesn't define _LP64. (gcc -m64 wasn't
Dave> useful when I last touched 64-bit sparc configuration.)
Well file does say that it is 64-bit version.
Dave>
Dave> Somewhere I have some changes to somewhat sanitize 64-bit
Dave> configuration, but as far as I know there are still some
Dave> basic problems with 64-bit systems, especially big-endian
Dave> ones, and I'm surprised they work at all...
I am not competent to comment on these. The first time I
compiled 64-bit emacs was sometimes in oct 2002. RMS had put
a request on the emacs-pretesters list for testing on 64 bit
machines. At that time, I could compile emacs. I could even
run it with "emacs -nw". X11 emacs used to dump core. It
seemed to be some openwin internal error. I had reported
all this on the emacs-pretesters list.
Now I work for a different organization. And 64-bit emacs
compiles have been running fine since last 3 months. I use
64-bit emacs for almost everything (including gnus etc.)
Dave> If it behaves differently on different Solaris systems with
Dave> the same OS version then you should probably look at all the
Dave> installed patches, versions of development tools (I assume
Dave> you use the Sun ld) and what you pick up from the system
Dave> libraries -- the version of malloc in particular.
I do use sun ld. I do not know how to check for which
malloc I am using. Should I send you the config.log file??
Dave> --
Regards
- p
--
Puneet Goel
TranSwitch India
--
LEAD me in the centre of thy silence
to fill my heart with songs.
-
Stray Birds, Rabindernath Tagore
--
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-08 15:18 Marshall, Simon
@ 2003-07-09 15:49 ` Richard Stallman
2003-07-11 9:57 ` Paul Eggert
1 sibling, 0 replies; 27+ messages in thread
From: Richard Stallman @ 2003-07-09 15:49 UTC (permalink / raw
Cc: emacs-pretesters, emacs-devel
The guys who first raised it on bugzilla had the same hunch. The
problem is: where do I start? I can't debug in __do_global_dtors_aux()
as there is no debugging info.
I think it has to be debugged at the assembler level anyway.
(That function is probably very simple--just look at the source
and you will see.)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-05 22:25 ` Richard Stallman
@ 2003-07-11 9:55 ` Paul Eggert
2003-07-11 22:52 ` Paul Eggert
2003-07-12 5:32 ` Richard Stallman
0 siblings, 2 replies; 27+ messages in thread
From: Paul Eggert @ 2003-07-11 9:55 UTC (permalink / raw
Cc: simon.marshall, emacs-pretesters, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 05 Jul 2003 18:25:56 -0400
>
> The way to debug this is to treat it as an Emacs bug. When you
> find the bug, it will actually be a miscompiled function (if this
> is GCC's fault). Then you can send a useful GCC bug report.
I looked into this a bit, and there seem to be at least two problems.
One is an Emacs portability problem; the rest I don't know yet.
Emacs assumes that a top-level declaration like "int pure[1000] = {0};"
puts "pure" into the data area. However, this assumption is no longer
true with GCC 3.3 on Solaris 8, which notices that "pure" has an
initializer that is all zeros, and puts "pure" into BSS instead.
This is a valid optimization, so I guess Emacs should deal with it.
I checked for all static variables that Emacs 21.3 defines to be zero
in Solaris 8, and which become readonly after dumping with GCC 3.2.3
but not with GCC 3.3, and I came up with the following patch to fix
this portability problem. This fixes part of the bug, but not all;
Emacs still dumps core. I'll see if I can investigate this further if
I find more time but that won't be before this weekend.
2003-07-11 Paul Eggert <eggert@twinsun.com>
GCC 3.3 no longer puts "int foo = 0;" into data; it optimizes
this case and puts it into BSS instead, at least on Solaris 8.
* src/alloc.c (pure, staticvec, staticidx):
Initialize to nonzero, so that it's data.
* src/emacs.c (bss_end): Likewise.
(main): Use bss_end==1 to mean it's unset.
The following changes don't fix any bugs, but they remove
initializations to zero that do not need to be in pure space.
I am including them in this patch (if only to document them).
* src/emacs.c (gdb_data_seg_bits): Do not initialize to zero
explicitly, since it's OK for this to be in BSS.
* src/xfns.c (cursor_bits): Likewise.
* src/xterm.c (Xt_default_resources): Likewise.
diff -pru emacs-21.3/src/alloc.c emacs-21.3-fix/src/alloc.c
--- emacs-21.3/src/alloc.c 2003-01-17 05:45:13.000000000 -0800
+++ emacs-21.3-fix/src/alloc.c 2003-07-11 02:02:37.215626000 -0700
@@ -188,7 +188,7 @@ Lisp_Object Vpurify_flag;
/* Force it into data space! */
-EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {0,};
+EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {1,};
#define PUREBEG (char *) pure
#else /* not HAVE_SHM */
@@ -395,11 +395,11 @@ struct gcpro *gcprolist;
/* Addresses of staticpro'd variables. */
#define NSTATICS 1024
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {1};
/* Index of next unused slot in staticvec. */
-int staticidx = 0;
+int staticidx = 1;
static POINTER_TYPE *pure_alloc P_ ((size_t, int));
diff -pru emacs-21.3/src/emacs.c emacs-21.3-fix/src/emacs.c
--- emacs-21.3/src/emacs.c 2002-08-29 12:27:07.000000000 -0700
+++ emacs-21.3-fix/src/emacs.c 2003-07-11 01:39:19.348060000 -0700
@@ -86,7 +86,7 @@ EMACS_INT gdb_emacs_intbits = sizeof (EM
#ifdef DATA_SEG_BITS
EMACS_INT gdb_data_seg_bits = DATA_SEG_BITS;
#else
-EMACS_INT gdb_data_seg_bits = 0;
+EMACS_INT gdb_data_seg_bits /* = 0 */;
#endif
EMACS_INT PVEC_FLAG = PSEUDOVECTOR_FLAG;
@@ -188,10 +188,10 @@ extern Lisp_Object Vwindow_system;
extern Lisp_Object Vauto_save_list_file_name;
#ifdef USG_SHARED_LIBRARIES
-/* If nonzero, this is the place to put the end of the writable segment
+/* If not 1, this is the place to put the end of the writable segment
at startup. */
-unsigned int bss_end = 0;
+unsigned int bss_end = 1;
#endif
/* Nonzero means running Emacs without interactive terminal. */
@@ -856,7 +856,7 @@ main (argc, argv, envp)
stack_bottom = &stack_bottom_variable;
#ifdef USG_SHARED_LIBRARIES
- if (bss_end)
+ if (bss_end != 1)
brk ((void *)bss_end);
#endif
diff -pru emacs-21.3/src/xfns.c emacs-21.3-fix/src/xfns.c
--- emacs-21.3/src/xfns.c 2002-12-06 09:05:35.000000000 -0800
+++ emacs-21.3-fix/src/xfns.c 2003-07-11 01:26:46.669033000 -0700
@@ -3954,13 +3954,7 @@ x_icon (f, parms)
background, border and mouse colors; also create the
mouse cursor and the gray border tile. */
-static char cursor_bits[] =
- {
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
- };
+static char cursor_bits[32];
static void
x_make_gc (f)
diff -pru emacs-21.3/src/xterm.c emacs-21.3-fix/src/xterm.c
--- emacs-21.3/src/xterm.c 2002-10-15 07:21:45.000000000 -0700
+++ emacs-21.3-fix/src/xterm.c 2003-07-11 01:25:07.789266000 -0700
@@ -284,7 +284,7 @@ struct frame *pending_autoraise_frame;
#ifdef USE_X_TOOLKIT
/* The application context for Xt use. */
XtAppContext Xt_app_con;
-static String Xt_default_resources[] = {0};
+static String Xt_default_resources[1];
#endif /* USE_X_TOOLKIT */
/* Nominal cursor position -- where to draw output.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-08 15:18 Marshall, Simon
2003-07-09 15:49 ` Richard Stallman
@ 2003-07-11 9:57 ` Paul Eggert
1 sibling, 0 replies; 27+ messages in thread
From: Paul Eggert @ 2003-07-11 9:57 UTC (permalink / raw
Cc: emacs-pretesters, emacs-devel
> From: "Marshall, Simon" <simon.marshall@misys.com>
> Date: Tue, 8 Jul 2003 16:18:10 +0100
>
> I can't debug in __do_global_dtors_aux()
> as there is no debugging info.
I am using the GDB "disas" command to disassemble
__do_global_dtors_aux into SPARC instructions.
(It's not a lot of fun.)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-11 9:55 ` Paul Eggert
@ 2003-07-11 22:52 ` Paul Eggert
2003-07-13 14:56 ` Simon Leinen
2003-07-12 5:32 ` Richard Stallman
1 sibling, 1 reply; 27+ messages in thread
From: Paul Eggert @ 2003-07-11 22:52 UTC (permalink / raw
Cc: simon.marshall, emacs-pretesters, emacs-devel
I found the other bug that was preventing Emacs 21.3 from building
with GCC 3.3 on Solaris 8 (sparc). Here is a patch. When I installed
this patch, together with the patch I sent earlier today, Emacs built
and installed on Solaris 8 with GCC 3.3, and ran OK on some simple
tests.
2003-07-11 Paul Eggert <eggert@twinsun.com>
* unexelf.c (unexec): Consider a section to precede the .bss
section if its addresses overlap that of .bss. This fixes the
bug reported by Simon Marshall in
<http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00033.html>,
if you also install the patch that I submitted yesterday in
<http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00207.html>.
This patch is related to my 1996-06-24 patch to unexelf.c
<http://www.geocrawler.com/archives/3/337/1996/6/0/1851704/>,
but it uses a more precise heuristic for deciding when the other
section precedes the .bss section.
--- emacs-21.3/src/unexelf.c 2002-10-15 07:21:44.000000000 -0700
+++ emacs-21.3-fix/src/unexelf.c 2003-07-11 14:59:48.649294000 -0700
@@ -971,8 +971,13 @@ unexec (new_name, old_name, data_start,
}
else
{
- /* Any section that was original placed AFTER the bss
- section should now be off by NEW_DATA2_SIZE. */
+ /* Any section that was originally placed after the .bss
+ section should now be off by NEW_DATA2_SIZE. If a
+ section overlaps the .bss section, consider it to be
+ placed after the .bss section. Overlap can occur if the
+ section just before .bss has less-strict alignment; this
+ was observed between .symtab and .bss on Solaris 2.5.1
+ (sparc) with GCC snapshot 960602. */
#ifdef SOLARIS_POWERPC
/* On PPC Reference Platform running Solaris 2.5.1
the plt section is also of type NOBI like the bss section.
@@ -986,9 +991,8 @@ unexec (new_name, old_name, data_start,
>= OLD_SECTION_H (old_bss_index-1).sh_offset)
NEW_SECTION_H (nn).sh_offset += new_data2_size;
#else
- if (round_up (NEW_SECTION_H (nn).sh_offset,
- OLD_SECTION_H (old_bss_index).sh_addralign)
- >= new_data2_offset)
+ if (NEW_SECTION_H (nn).sh_offset + NEW_SECTION_H (nn).sh_size
+ > new_data2_offset)
NEW_SECTION_H (nn).sh_offset += new_data2_size;
#endif
/* Any section that was originally placed after the section
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-11 9:55 ` Paul Eggert
2003-07-11 22:52 ` Paul Eggert
@ 2003-07-12 5:32 ` Richard Stallman
1 sibling, 0 replies; 27+ messages in thread
From: Richard Stallman @ 2003-07-12 5:32 UTC (permalink / raw
Cc: simon.marshall, emacs-pretesters, emacs-devel
Thanks. Would someone please install these changes?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-11 22:52 ` Paul Eggert
@ 2003-07-13 14:56 ` Simon Leinen
2003-07-14 5:52 ` Paul Eggert
0 siblings, 1 reply; 27+ messages in thread
From: Simon Leinen @ 2003-07-13 14:56 UTC (permalink / raw
Cc: simon.marshall, emacs-pretesters, rms, emacs-devel
Paul,
THANK YOU! Your two patches makes Emacs 21.3 work well for me on
Solaris 9 in 64-bit mode using GCC 3.3.
Do you think it would be useful for me to test your patches in other
compilation modes as well?
Regards,
--
Simon.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-13 14:56 ` Simon Leinen
@ 2003-07-14 5:52 ` Paul Eggert
0 siblings, 0 replies; 27+ messages in thread
From: Paul Eggert @ 2003-07-14 5:52 UTC (permalink / raw
Cc: simon.marshall, emacs-pretesters, emacs-devel
> From: Simon Leinen <simon@limmat.switch.ch>
> Date: Sun, 13 Jul 2003 16:56:09 +0200
>
> Do you think it would be useful for me to test your patches in other
> compilation modes as well?
I am testing 32-bit Solaris sparc (both Solaris 8 and 9) in everyday
use, so you needn't bother with those cases. It'd be nice to test it
on older Solaris releases.
However, I discovered that the zero-initializer changes
<http://mail.gnu.org/archive/html/emacs-devel/2003-07/msg00207.html>
are not needed on Solaris 8 or 9, since unexelf.c does not attempt to
make any of the initialized data read-only.
On further thought, those changes are not urgent: they are only an
optimization, and they help only on hosts where dumping the 'pure'
array into readonly text is a real performance win. This used to be a
big deal (15 years ago, say), but I suspect it's not that important
these days. Certainly small things like scalars are not worth
worrying about now, from a performance viewpoint; only arrays like
'pure' matter.
Since the zero-initializer changes don't fix any real bug that I know
of, I didn't install them into the RC branch. And I omitted the
proposed changes to scalars, leaving only the following small change
that I just installed into the trunk.
2003-07-13 Paul Eggert <eggert@twinsun.com>
GCC 3.3 (sparc) no longer puts "int foo = 0;" into data; it
puts it into BSS instead, at least on Solaris 8 and 9.
This is a valid optimization, and it may occur on other platforms,
so Emacs should not assume that initializing a static variable to
zero puts it into data.
* alloc.c (pure, staticvec):
Initialize these arrays to nonzero, so that they're not
put into BSS by that optimization.
Index: alloc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/alloc.c,v
retrieving revision 1.314
retrieving revision 1.315
diff -p -u -r1.314 -r1.315
--- alloc.c 14 Jul 2003 02:51:08 -0000 1.314
+++ alloc.c 14 Jul 2003 05:37:52 -0000 1.315
@@ -185,9 +185,10 @@ Lisp_Object Vmemory_full;
#ifndef HAVE_SHM
-/* Force it into data space! */
+/* Force it into data space! Initialize it to a nonzero value;
+ otherwise some compilers put it into BSS. */
-EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {0,};
+EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {1,};
#define PUREBEG (char *) pure
#else /* HAVE_SHM */
@@ -404,10 +405,11 @@ static void check_gcpros P_ ((void));
struct gcpro *gcprolist;
-/* Addresses of staticpro'd variables. */
+/* Addresses of staticpro'd variables. Initialize it to a nonzero
+ value; otherwise some compilers put it into BSS. */
#define NSTATICS 1280
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {&Vpurify_flag};
/* Index of next unused slot in staticvec. */
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: Anyone built Emacs with gcc-3.3?
@ 2003-07-14 11:19 Marshall, Simon
[not found] ` <3F12B8E7.2C387FE7@yk.rim.or.jp>
2003-07-14 17:47 ` Paul Eggert
0 siblings, 2 replies; 27+ messages in thread
From: Marshall, Simon @ 2003-07-14 11:19 UTC (permalink / raw
Cc: 'emacs-pretesters@gnu.org', 'emacs-devel@gnu.org',
'ebotcazou@gcc.gnu.org', 'ishikawa@yk.rim.or.jp'
Paul, thanks. I can confirm that Emacs builds OK for me on s8 with
gcc-3.3 with the below Emacs patches plus your unexelf.c patch. (Eric's
patch was not relevant for me anyway as I don't build with Xaw.)
I do get a gripe though:
alloc.c:398: warning: initialization makes pointer from integer without
a cast
due to this change:
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {1};
Casting 1 with (Lisp_Object *) keeps gcc happy; so does removing the
initialisation. I'll leave someone else to work out the correct way to
deal with this.
Thanks to everyone for sorting this out. Simon.
-----Original Message-----
From: Marshall, Simon
Sent: 11 July 2003 11:38
To: 'Paul Eggert'
Cc: 'ebotcazou@gcc.gnu.org'; 'ishikawa@yk.rim.or.jp'
Subject: RE: Anyone built Emacs with gcc-3.3?
Paul, many thanks. FYI, I put your email on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386, seeing as they have
also looked at it with objdump. Your input may help them and vice
versa.
I hope this can be fixed for 3.3.1, rather than the target 3.3.2.
Simon.
-----Original Message-----
From: Paul Eggert [mailto:eggert@twinsun.com]
Sent: 11 July 2003 10:55
To: rms@gnu.org
Cc: simon.marshall@misys.com; emacs-devel@gnu.org;
emacs-pretesters@gnu.org
Subject: Re: Anyone built Emacs with gcc-3.3?
> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 05 Jul 2003 18:25:56 -0400
>
> The way to debug this is to treat it as an Emacs bug. When you
> find the bug, it will actually be a miscompiled function (if this
> is GCC's fault). Then you can send a useful GCC bug report.
I looked into this a bit, and there seem to be at least two problems.
One is an Emacs portability problem; the rest I don't know yet.
Emacs assumes that a top-level declaration like "int pure[1000] = {0};"
puts "pure" into the data area. However, this assumption is no longer
true with GCC 3.3 on Solaris 8, which notices that "pure" has an
initializer that is all zeros, and puts "pure" into BSS instead.
This is a valid optimization, so I guess Emacs should deal with it.
I checked for all static variables that Emacs 21.3 defines to be zero
in Solaris 8, and which become readonly after dumping with GCC 3.2.3
but not with GCC 3.3, and I came up with the following patch to fix
this portability problem. This fixes part of the bug, but not all;
Emacs still dumps core. I'll see if I can investigate this further if
I find more time but that won't be before this weekend.
2003-07-11 Paul Eggert <eggert@twinsun.com>
GCC 3.3 no longer puts "int foo = 0;" into data; it optimizes
this case and puts it into BSS instead, at least on Solaris 8.
* src/alloc.c (pure, staticvec, staticidx):
Initialize to nonzero, so that it's data.
* src/emacs.c (bss_end): Likewise.
(main): Use bss_end==1 to mean it's unset.
The following changes don't fix any bugs, but they remove
initializations to zero that do not need to be in pure space.
I am including them in this patch (if only to document them).
* src/emacs.c (gdb_data_seg_bits): Do not initialize to zero
explicitly, since it's OK for this to be in BSS.
* src/xfns.c (cursor_bits): Likewise.
* src/xterm.c (Xt_default_resources): Likewise.
diff -pru emacs-21.3/src/alloc.c emacs-21.3-fix/src/alloc.c
--- emacs-21.3/src/alloc.c 2003-01-17 05:45:13.000000000 -0800
+++ emacs-21.3-fix/src/alloc.c 2003-07-11 02:02:37.215626000 -0700
@@ -188,7 +188,7 @@ Lisp_Object Vpurify_flag;
/* Force it into data space! */
-EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {0,};
+EMACS_INT pure[PURESIZE / sizeof (EMACS_INT)] = {1,};
#define PUREBEG (char *) pure
#else /* not HAVE_SHM */
@@ -395,11 +395,11 @@ struct gcpro *gcprolist;
/* Addresses of staticpro'd variables. */
#define NSTATICS 1024
-Lisp_Object *staticvec[NSTATICS] = {0};
+Lisp_Object *staticvec[NSTATICS] = {1};
/* Index of next unused slot in staticvec. */
-int staticidx = 0;
+int staticidx = 1;
static POINTER_TYPE *pure_alloc P_ ((size_t, int));
diff -pru emacs-21.3/src/emacs.c emacs-21.3-fix/src/emacs.c
--- emacs-21.3/src/emacs.c 2002-08-29 12:27:07.000000000 -0700
+++ emacs-21.3-fix/src/emacs.c 2003-07-11 01:39:19.348060000 -0700
@@ -86,7 +86,7 @@ EMACS_INT gdb_emacs_intbits = sizeof (EM
#ifdef DATA_SEG_BITS
EMACS_INT gdb_data_seg_bits = DATA_SEG_BITS;
#else
-EMACS_INT gdb_data_seg_bits = 0;
+EMACS_INT gdb_data_seg_bits /* = 0 */;
#endif
EMACS_INT PVEC_FLAG = PSEUDOVECTOR_FLAG;
@@ -188,10 +188,10 @@ extern Lisp_Object Vwindow_system;
extern Lisp_Object Vauto_save_list_file_name;
#ifdef USG_SHARED_LIBRARIES
-/* If nonzero, this is the place to put the end of the writable segment
+/* If not 1, this is the place to put the end of the writable segment
at startup. */
-unsigned int bss_end = 0;
+unsigned int bss_end = 1;
#endif
/* Nonzero means running Emacs without interactive terminal. */
@@ -856,7 +856,7 @@ main (argc, argv, envp)
stack_bottom = &stack_bottom_variable;
#ifdef USG_SHARED_LIBRARIES
- if (bss_end)
+ if (bss_end != 1)
brk ((void *)bss_end);
#endif
diff -pru emacs-21.3/src/xfns.c emacs-21.3-fix/src/xfns.c
--- emacs-21.3/src/xfns.c 2002-12-06 09:05:35.000000000 -0800
+++ emacs-21.3-fix/src/xfns.c 2003-07-11 01:26:46.669033000 -0700
@@ -3954,13 +3954,7 @@ x_icon (f, parms)
background, border and mouse colors; also create the
mouse cursor and the gray border tile. */
-static char cursor_bits[] =
- {
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
- };
+static char cursor_bits[32];
static void
x_make_gc (f)
diff -pru emacs-21.3/src/xterm.c emacs-21.3-fix/src/xterm.c
--- emacs-21.3/src/xterm.c 2002-10-15 07:21:45.000000000 -0700
+++ emacs-21.3-fix/src/xterm.c 2003-07-11 01:25:07.789266000 -0700
@@ -284,7 +284,7 @@ struct frame *pending_autoraise_frame;
#ifdef USE_X_TOOLKIT
/* The application context for Xt use. */
XtAppContext Xt_app_con;
-static String Xt_default_resources[] = {0};
+static String Xt_default_resources[1];
#endif /* USE_X_TOOLKIT */
/* Nominal cursor position -- where to draw output.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
[not found] ` <3F12B8E7.2C387FE7@yk.rim.or.jp>
@ 2003-07-14 14:41 ` Eric Botcazou
0 siblings, 0 replies; 27+ messages in thread
From: Eric Botcazou @ 2003-07-14 14:41 UTC (permalink / raw
Cc: 'Paul Eggert', Marshall, Simon,
'emacs-pretesters@gnu.org', 'emacs-devel@gnu.org'
> I thought an additional
> post explaining the resolution (Paul's patch to
> emacs initialization statement and to unexelf.c)
> and pointing to appropriate URL of the mailing
> list archive would be helpful.
Please add these informations to the GCC bugzilla entry. I don't think the
"resolved" state prevents this.
Thanks.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-14 11:19 Marshall, Simon
[not found] ` <3F12B8E7.2C387FE7@yk.rim.or.jp>
@ 2003-07-14 17:47 ` Paul Eggert
2003-07-14 19:40 ` Eric Botcazou
1 sibling, 1 reply; 27+ messages in thread
From: Paul Eggert @ 2003-07-14 17:47 UTC (permalink / raw
Cc: emacs-pretesters, emacs-devel, ebotcazou, ishikawa
> From: "Marshall, Simon" <simon.marshall@misys.com>
> 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};
> Date: Mon, 14 Jul 2003 23:06:31 +0900
> From: Ishikawa <ishikawa@yk.rim.or.jp>
> (Strangely, I didn't have to apply the patch Eric posted. I suspect
> that there may be a factor due to different version of Sun's ld.
As I understand it, the bug does not always occur: it depends on the
layouts of the earlier segments. So it's possible that Eric's patch
happened to fix the problem for his particular alignment, even though
it shouldn't fix the problem in general (and didn't work for me).
> I didn't notice the warning Simon caught because I was
> so ecstatic that "make" ended successfully.
> I should have scrolled up a little bit to see some warning messages.
Yes, that's what happened with me too.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-14 17:47 ` Paul Eggert
@ 2003-07-14 19:40 ` Eric Botcazou
0 siblings, 0 replies; 27+ messages in thread
From: Eric Botcazou @ 2003-07-14 19:40 UTC (permalink / raw
Cc: emacs-pretesters, simon.marshall, emacs-devel, ishikawa
> As I understand it, the bug does not always occur: it depends on the
> layouts of the earlier segments. So it's possible that Eric's patch
> happened to fix the problem for his particular alignment, even though
> it shouldn't fix the problem in general (and didn't work for me).
Yes, and I recently learnt that this whole business could simply be avoided
by specifying -fno-zero-initialized-in-bss on the command line...
--
Eric Botcazou
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Anyone built Emacs with gcc-3.3?
2003-07-09 12:31 ` Puneet Goel
@ 2003-07-15 22:31 ` Dave Love
0 siblings, 0 replies; 27+ messages in thread
From: Dave Love @ 2003-07-15 22:31 UTC (permalink / raw
Cc: 'Emacs Pretesters', Marshall, Simon,
'Emacs Developers', puneet
Puneet Goel <pgoel@txc.stpn.soft.net> writes:
> I am sure that my emacs is 64-bit because ....
>
> 1. I use gcc -m64 to compile that.
Right, that's the relevant option with gcc. I mentioned it to try to
avoid confusion. Sorry I misremembered that I did make it work on
SPARC, although gcc supposedly didn't generate reliable code at the
time.
> I do use sun ld. I do not know how to check for which
> malloc I am using. Should I send you the config.log file??
Actually, that wasn't relevant, because Solaris uses gmalloc now --
something else I mis-remembered.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2003-07-15 22:31 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-07 8:26 Anyone built Emacs with gcc-3.3? Marshall, Simon
2003-07-08 14:28 ` Richard Stallman
2003-07-08 14:39 ` Jason Rumney
2003-07-09 5:34 ` Dhruva Krishnamurthy
2003-07-09 7:36 ` Pascal Obry
2003-07-09 7:59 ` Jason Rumney
-- strict thread matches above, loose matches on Subject: below --
2003-07-14 11:19 Marshall, Simon
[not found] ` <3F12B8E7.2C387FE7@yk.rim.or.jp>
2003-07-14 14:41 ` Eric Botcazou
2003-07-14 17:47 ` Paul Eggert
2003-07-14 19:40 ` Eric Botcazou
2003-07-08 15:18 Marshall, Simon
2003-07-09 15:49 ` Richard Stallman
2003-07-11 9:57 ` Paul Eggert
2003-07-04 12:36 Nelson H. F. Beebe
2003-07-04 8:33 Marshall, Simon
2003-07-04 8:41 ` Dhruva Krishnamurthy
2003-07-04 16:17 ` puneet
2003-07-08 22:41 ` Dave Love
2003-07-09 12:31 ` Puneet Goel
2003-07-15 22:31 ` Dave Love
2003-07-05 22:25 ` Richard Stallman
2003-07-11 9:55 ` Paul Eggert
2003-07-11 22:52 ` Paul Eggert
2003-07-13 14:56 ` Simon Leinen
2003-07-14 5:52 ` Paul Eggert
2003-07-12 5:32 ` Richard Stallman
2003-07-08 22:30 ` Dave Love
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).