* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
@ 2013-01-10 17:46 Gilles Pion
2013-01-11 6:26 ` Glenn Morris
2013-01-11 8:03 ` Paul Eggert
0 siblings, 2 replies; 6+ messages in thread
From: Gilles Pion @ 2013-01-10 17:46 UTC (permalink / raw)
To: 13408
[-- Attachment #1.1: Type: text/plain, Size: 3286 bytes --]
*1st compilation error:*
sysdep.c: In function 'init_signals':
sysdep.c:1940:34: error: 'deliver_danger_signal' undeclared (first use in
this function)
sysdep.c:1940:34: note: each undeclared identifier is reported only once
for each function it appears in
gmake[1]: *** [sysdep.o] Error 1
gmake[1]: Leaving directory
`/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src'
gmake: *** [src] Error 2
Have bee able to fix by adding declaration of "deliver_danger_signal"
in sysdep.c:
void deliver_danger_signal (int sig);
*2nd compilation error:*
(did not found a easy way to fix)
/fdj/opt/gcc-4.7/bin/gcc -std=gnu99 -c -Demacs -I.
-I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src -I../lib
-I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src/../lib
-MMD -MF deps/eval.d -MP -O2 -I/opt/freeware/include eval.c
eval.c: In function 'mark_backtrace':
eval.c:3380:20: error: invalid type argument of unary '*' (have
'Lisp_Object')
gmake[1]: *** [eval.o] Error 1
gmake[1]: Leaving directory
`/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src'
gmake: *** [src] Error 2
*
*
Context:
$ /fdj/opt/gcc-4.7/bin/gcc --version
gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Where should the build process find the source code?
/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92
What compiler should emacs be built with?
/fdj/opt/gcc-4.7/bin/gcc -std=gnu99 -O2 -I/opt/freeware/include
Should Emacs use the GNU version of malloc? yes
Should Emacs use a relocating allocator for buffers? yes
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? x11
What toolkit should Emacs use? LUCID
Where do we find X Windows header files? Standard dirs
Where do we find X Windows libraries? Standard dirs
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? yes
Does Emacs use -ljpeg? no
Does Emacs use -ltiff? no
Does Emacs use a gif library? no
Does Emacs use -lpng? no
Does Emacs use -lrsvg-2? no
Does Emacs use imagemagick? no
Does Emacs use -lgpm? no
Does Emacs use -ldbus? no
Does Emacs use -lgconf? no
Does Emacs use GSettings? no
Does Emacs use -lselinux? no
Does Emacs use -lgnutls? no
Does Emacs use -lxml2? no
Does Emacs use -lfreetype? no
Does Emacs use -lm17n-flt? no
Does Emacs use -lotf? no
Does Emacs use -lxft? no
Does Emacs use toolkit scroll bars? no
--
Gilles PION
[-- Attachment #1.2: Type: text/html, Size: 6541 bytes --]
[-- Attachment #2: config.txt --]
[-- Type: text/plain, Size: 1226 bytes --]
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by emacs configure 24.2.92, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ ./configure --prefix=/fdj/opt/emacs-24.2.92 --exec-prefix=/fdj/opt/emacs-24.2.92 --sysconfdir=/etc/fdj/opt/emacs --localstatedir=/var/fdj/opt/emacs --without-kerberos --without-pop --with-x-toolkit=lucid --without-sound --without-kerberos --without-kerberos5 --with-jpeg=no --with-png=no --with-gif=no --with-tiff=no --with-xpm --without-toolkit-scroll-bars --enable-locallisppath=/fdj/share/emacs/site-lisp --without-makeinfo
## --------- ##
## Platform. ##
## --------- ##
hostname = ax210
uname -m = 00CD11A44C00
uname -r = 3
uname -s = AIX
uname -v = 5
/usr/bin/uname -p = powerpc
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = 5.3.0.0
/bin/universe = unknown
PATH: /usr/vac/bin
PATH: /usr/vacpp/bin
PATH: /usr/local/bin
PATH: /bin
PATH: /usr/bin
PATH: /usr/ccs/bin
PATH: /opt/freeware/bin
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-10 17:46 bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2 Gilles Pion
@ 2013-01-11 6:26 ` Glenn Morris
2013-01-11 8:24 ` Eli Zaretskii
2013-01-11 8:03 ` Paul Eggert
1 sibling, 1 reply; 6+ messages in thread
From: Glenn Morris @ 2013-01-11 6:26 UTC (permalink / raw)
To: Gilles Pion; +Cc: 13408
Gilles Pion wrote:
> sysdep.c: In function 'init_signals':
> sysdep.c:1940:34: error: 'deliver_danger_signal' undeclared (first use in
> this function)
[...]
> Have bee able to fix by adding declaration of "deliver_danger_signal"
> in sysdep.c:
>
> void deliver_danger_signal (int sig);
Or maybe just move handle_danger_signal and deliver_danger_signal
entirely from emacs.c to sysdep.c? That's the only file that uses them,
and eg handle_fatal_signal/deliver_fatal_signal are already there.
> /fdj/opt/gcc-4.7/bin/gcc -std=gnu99 -c -Demacs -I.
> -I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src -I../lib
> -I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src/../lib
> -MMD -MF deps/eval.d -MP -O2 -I/opt/freeware/include eval.c
> eval.c: In function 'mark_backtrace':
> eval.c:3380:20: error: invalid type argument of unary '*' (have
> 'Lisp_Object')
Does anyone see what the problem is here?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-10 17:46 bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2 Gilles Pion
2013-01-11 6:26 ` Glenn Morris
@ 2013-01-11 8:03 ` Paul Eggert
2013-01-11 9:15 ` Eli Zaretskii
1 sibling, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2013-01-11 8:03 UTC (permalink / raw)
To: 13408-done
Glenn's suggestion for moving handle_danger_signal and deliver_danger_signal
seems good, so I installed a patch to do that, as emacs-24 bzr 111170.
The other problem is due to a stray '*'. This was fixed a while ago
in the trunk, so I backported that to emacs-24 as bzr 111171.
I'll be optimistic and close the bug as fixed; if I'm wrong I'll
reopen it.
Here are the URLs for these two fixes.
http://bzr.savannah.gnu.org/lh/emacs/emacs-24/revision/111170
http://bzr.savannah.gnu.org/lh/emacs/emacs-24/revision/111171
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-11 6:26 ` Glenn Morris
@ 2013-01-11 8:24 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2013-01-11 8:24 UTC (permalink / raw)
To: Glenn Morris; +Cc: gpion, 13408
> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 11 Jan 2013 01:26:15 -0500
> Cc: 13408@debbugs.gnu.org
>
> > /fdj/opt/gcc-4.7/bin/gcc -std=gnu99 -c -Demacs -I.
> > -I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src -I../lib
> > -I/sg/paxdev5/D1stunix/src/emacs/24.2.92/emacs-24.2.92/src/../lib
> > -MMD -MF deps/eval.d -MP -O2 -I/opt/freeware/include eval.c
> > eval.c: In function 'mark_backtrace':
> > eval.c:3380:20: error: invalid type argument of unary '*' (have
> > 'Lisp_Object')
>
> Does anyone see what the problem is here?
This is the code in question, with line 3380 the last one:
void
mark_backtrace (void)
{
register struct backtrace *backlist;
ptrdiff_t i;
for (backlist = backtrace_list; backlist; backlist = backlist->next)
{
mark_object (*backlist->function);
Shouldn't it be
mark_object (backlist->function);
instead?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-11 8:03 ` Paul Eggert
@ 2013-01-11 9:15 ` Eli Zaretskii
2013-01-11 19:11 ` Paul Eggert
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2013-01-11 9:15 UTC (permalink / raw)
To: Paul Eggert; +Cc: gpion, 13408
> Date: Fri, 11 Jan 2013 00:03:39 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
>
> The other problem is due to a stray '*'. This was fixed a while ago
> in the trunk, so I backported that to emacs-24 as bzr 111171.
Do you happen to know what did GCC make out that, before the change?
Did it just ignore the dereference?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2
2013-01-11 9:15 ` Eli Zaretskii
@ 2013-01-11 19:11 ` Paul Eggert
0 siblings, 0 replies; 6+ messages in thread
From: Paul Eggert @ 2013-01-11 19:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gpion, 13408
On 01/11/2013 01:15 AM, Eli Zaretskii wrote:
>> Date: Fri, 11 Jan 2013 00:03:39 -0800
>> > From: Paul Eggert <eggert@cs.ucla.edu>
>> >
>> > The other problem is due to a stray '*'. This was fixed a while ago
>> > in the trunk, so I backported that to emacs-24 as bzr 111171.
> Do you happen to know what did GCC make out that, before the change?
> Did it just ignore the dereference?
No, GCC consistently refused to compile it. It's just that
this code is rarely compiled -- it's normally ifdeffed out,
so GCC doesn't see the problem. I suppose that on AIX the
code is not ifdeffed out, so that's why the bug was reported
for AIX.
In older Emacs versions, the types were different and the
"*" was OK; it became a stray "*" only fairly recently.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-01-11 19:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-10 17:46 bug#13408: Emacs pretest 24.2.92 - compilation error on AIX 5.3 using gcc 4.7-2 Gilles Pion
2013-01-11 6:26 ` Glenn Morris
2013-01-11 8:24 ` Eli Zaretskii
2013-01-11 8:03 ` Paul Eggert
2013-01-11 9:15 ` Eli Zaretskii
2013-01-11 19:11 ` Paul Eggert
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).