zsh 4.3.2 bug

zsh 4.3.2 bug

[g.fischer]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]


hello,

tried to build 4.3.2 on irix 6.5.29 with mipspro 7.43 but got:
/
gmake[2]: Entering directory `/mnt/3/temp/zsh-4.3.2/Src'
c99 -c -I. -I/usr/local/include -I/usr/local2/include 
-I/usr/nekoware/include -I/usr/freeware/include -DHAVE_CONFIG_H -O3 
-mips4 -lfastm -lm -TARG:platform=IP27:proc=r12000 
-OPT:Olimit=0:roundoff=3:IEEE_arithmetic=3  -o builtin.o builtin.c
cc-1020 c99: ERROR File = signals.epro, Line = 5
  The identifier "SIGCOUNT" is undefined.

  extern mod_import_variable int sigtrapped[VSIGCOUNT];
                                            ^

cc-1020 c99: ERROR File = builtin.c, Line = 5060
  The identifier "sigs" is undefined.

        if (!strcmp(sigs[sig], *argv))
                    ^

2 errors detected in the compilation of "builtin.c".
gmake[2]: *** [builtin.o] Error 2/


maybe you have any hints.

thanks in advance

-- 
AH Computer-Systeme
Goetz Fischer
Senior Consultant
Phone: +49(0)7225/98 98 79
Fax:   +49(0)7225/28 64
eMail: g.fischer@ah-online.com
http://www.ah-online.com
http://www.ah-webhosting.com


[-- Attachment #2: Type: text/html, Size: 1928 bytes --]

Re: zsh 4.3.2 bug

[Peter Stephenson]

"g.fischer@ah-online.com" <g.fischer@ah-online.com> wrote:
> tried to build 4.3.2 on irix 6.5.29 with mipspro 7.43 but got:
> /
> gmake[2]: Entering directory `/mnt/3/temp/zsh-4.3.2/Src'
> c99 -c -I. -I/usr/local/include -I/usr/local2/include 
> -I/usr/nekoware/include -I/usr/freeware/include -DHAVE_CONFIG_H -O3 
> -mips4 -lfastm -lm -TARG:platform=IP27:proc=r12000 
> -OPT:Olimit=0:roundoff=3:IEEE_arithmetic=3  -o builtin.o builtin.c
> cc-1020 c99: ERROR File = signals.epro, Line = 5
>   The identifier "SIGCOUNT" is undefined.
> 
>   extern mod_import_variable int sigtrapped[VSIGCOUNT];

The MACHINES file recommends using gcc for building zsh, but we rely on
other people's reports for getting IRIX to work so I don't have any more
detail.  Something very close to 4.3.2 was reported to compile on
6.5.something.


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

Re: zsh 4.3.2 bug

[goetz fischer]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

Peter Stephenson wrote:

> "g.fischer@ah-online.com" <g.fischer@ah-online.com> wrote:
> > tried to build 4.3.2 on irix 6.5.29 with mipspro 7.43 but got:
> > /
> > gmake[2]: Entering directory `/mnt/3/temp/zsh-4.3.2/Src'
> > c99 -c -I. -I/usr/local/include -I/usr/local2/include
> > -I/usr/nekoware/include -I/usr/freeware/include -DHAVE_CONFIG_H -O3
> > -mips4 -lfastm -lm -TARG:platform=IP27:proc=r12000
> > -OPT:Olimit=0:roundoff=3:IEEE_arithmetic=3  -o builtin.o builtin.c
> > cc-1020 c99: ERROR File = signals.epro, Line = 5
> >   The identifier "SIGCOUNT" is undefined.
> >
> >   extern mod_import_variable int sigtrapped[VSIGCOUNT];
>
> The MACHINES file recommends using gcc for building zsh,

sorry but gcc for major stuff like a shell is not an option.

> but we rely on
> other people's reports for getting IRIX to work so I don't have any more
> detail.  Something very close to 4.3.2 was reported to compile on
> 6.5.something.

okay so i'll give 4.3.1 a try.
thanks so far

>
>
> To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php

--
ah-consulting.net
Götz Fischer
Senior Consultant
Phone: +49(0)7225/98 98 79
Fax:   +49(0)7225/28 64
eMail: g.fischer@ah-consulting.net
http://www.ah-consulting.net
http://www.ah-webhosting.com



[-- Attachment #2: Type: text/html, Size: 1707 bytes --]

Re: zsh 4.3.2 bug

[Wayne Davison]

On Wed, Mar 15, 2006 at 12:37:49AM +0100, goetz fischer wrote:
> okay so i'll give 4.3.1 a try.

I doubt that will make a difference.  What you need to figure out is why
the building of the signames.c file failed.  The make rules are this
(taken from Makemod.in):

 signames.c: signames1.awk signames2.awk ../config.h @SIGNAL_H@
        $(AWK) -f $(sdir)/signames1.awk @SIGNAL_H@ >sigtmp.c
        $(CPP) sigtmp.c >sigtmp.out
        $(AWK) -f $(sdir)/signames2.awk sigtmp.out > $@
        rm -f sigtmp.c sigtmp.out

 sigcount.h: signames.c
        grep 'define.*SIGCOUNT' signames.c > $@

My generated Makemod file has "/usr/include/bits/signum.h" in place of
the @SIGNAL_H@ value.  Those awk and cpp commands should generate a file
named signames.c that should have a define for SIGCOUNT in it, e.g.:

#define SIGCOUNT        31

It should also define an array named sigs[], e.g.:

char *sigs[SIGCOUNT+4] = {
        "EXIT",
        "HUP",
        "INT",
	[...]

Perhaps your awk didn't work right?  Or perhaps the SIGNAL_H file wasn't
chosen correctly?

Once the signames.c file gets built right, then the sigcount.h file
should end up with two lines in it.  Mine is this:

#define SIGCOUNT        31
#define sigmsg(sig) ((sig) <= SIGCOUNT ? sig_msg[sig] : "unknown signal")

At that point, the build errors you cited should go away.

..wayne..

Re: zsh 4.3.2 bug

[g.fischer]

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

Wayne Davison wrote:
> On Wed, Mar 15, 2006 at 12:37:49AM +0100, goetz fischer wrote:
>   
>> okay so i'll give 4.3.1 a try.
>>     
>
> I doubt that will make a difference.
according to the first answer i got somebody made an almost 4.3.2 
version compile so i thought 4.3.1 might be a good bet.
>   What you need to figure out is why
> the building of the signames.c file failed.  The make rules are this
> (taken from Makemod.in):
>
>  signames.c: signames1.awk signames2.awk ../config.h @SIGNAL_H@
>         $(AWK) -f $(sdir)/signames1.awk @SIGNAL_H@ >sigtmp.c
>         $(CPP) sigtmp.c >sigtmp.out
>         $(AWK) -f $(sdir)/signames2.awk sigtmp.out > $@
>         rm -f sigtmp.c sigtmp.out
>
>  sigcount.h: signames.c
>         grep 'define.*SIGCOUNT' signames.c > $@
>
> My generated Makemod file has "/usr/include/bits/signum.h" in place of
> the @SIGNAL_H@ value.  Those awk and cpp commands should generate a file
> named signames.c that should have a define for SIGCOUNT in it, e.g.:
>
> #define SIGCOUNT        31
>
> It should also define an array named sigs[], e.g.:
>
> char *sigs[SIGCOUNT+4] = {
>         "EXIT",
>         "HUP",
>         "INT",
> 	[...]
>
> Perhaps your awk didn't work right?  Or perhaps the SIGNAL_H file wasn't
> chosen correctly?
>
> Once the signames.c file gets built right, then the sigcount.h file
> should end up with two lines in it.  Mine is this:
>
> #define SIGCOUNT        31
> #define sigmsg(sig) ((sig) <= SIGCOUNT ? sig_msg[sig] : "unknown signal")
>
> At that point, the build errors you cited should go away.
>   
okay, thanks so far.
i'll try to find the respective header.
> ..wayne..
>   

-- 
ah-consulting.net
Götz Fischer
Senior Consultant
Phone: +49(0)7225/98 98 79
Fax:   +49(0)7225/28 64
eMail: g.fischer@ah-consulting.net
http://www.ah-consulting.net
http://www.ah-webhosting.com


[-- Attachment #2: Type: text/html, Size: 2702 bytes --]

Re: zsh 4.3.2 bug

[Peter Stephenson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

"g.fischer@ah-online.com" wrote:
> François-Xavier Coudert wrote:
> > I just compiled zsh-4.3.2 fine with:
> >
> > CC=cc ./configure --prefix=/tmp/zsh-install --enable-multibyte && make
> > && make install
> >   
> yeah, it worked. just added --enable-multibyte and it ran like a charm.
> much thanks!!

I think this means the following...

Index: MACHINES
===================================================================
RCS file: /cvsroot/zsh/zsh/MACHINES,v
retrieving revision 1.2
diff -u -r1.2 MACHINES
--- MACHINES	2 Mar 2006 14:26:20 -0000	1.2
+++ MACHINES	19 Mar 2006 19:36:52 -0000
@@ -178,8 +178,11 @@
 	Should build `out-of-the-box'.
 
 SGI: IRIX 6.5
-	Should build `out-of-the-box'.
-	Use of gcc for compilation is recommended.
+	Should build `out-of-the-box'; however, if using the native
+	compiler, "cc" rather than "c99" is recommended.  Compilation
+	with gcc is also reported to work.  Multibyte is supported,
+	for example:
+           CC=cc ./configure --enable-multibyte
 
 	On 6.5.2, zsh malloc routines are reported not to work; also
 	full optimization (cc -O3 -OPT:Olimit=0) causes problems.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page still at http://www.pwstephenson.fsnet.co.uk/

Re: zsh 4.3.2 bug

[g.fischer]

François-Xavier Coudert wrote:
> I just compiled zsh-4.3.2 fine with:
>
> CC=cc ./configure --prefix=/tmp/zsh-install --enable-multibyte && make
> && make install
>   
yeah, it worked. just added --enable-multibyte and it ran like a charm.
much thanks!!
> I have the following configuration:
>
> $ uname -a
> IRIX64 xxx 6.5 10060437 IP27 mips unknown Irix
> $ cc -v
> MIPSpro Compilers: Version 7.4.2m
>
> Maybe switching from c99 to cc would to the trick?
>
> FX
>   

-- 
AH Computer-Systeme
Goetz Fischer
Senior Consultant
Phone: +49(0)7225/98 98 79
Fax:   +49(0)7225/28 64
eMail: g.fischer@ah-online.com
http://www.ah-online.com
http://www.ah-webhosting.com

Re: zsh 4.3.2 bug

[FX Coudert]

Le 17 mars 06, à 19:46, Wayne Davison a écrit :

> On Fri, Mar 17, 2006 at 06:45:53PM +0100, Fran?ois-Xavier Coudert 
> wrote:
>> $ uname -a
>> IRIX64 xxx 6.5 10060437 IP27 mips unknown Irix
>> $ cc -v
>> MIPSpro Compilers: Version 7.4.2m
>
> What are you using for awk?  Is is gawk? mawk? nawk? awk?

$ which awk
/usr/bin/awk
$ awk -v
UX:awk: ERROR: No program given
$ awk -help
UX:awk: WARNING: Unknown option -help ignored
UX:awk: ERROR: No program given
$ awk -V
UX:awk: WARNING: Unknown option -V ignored
UX:awk: ERROR: No program given

Doesn't help much :)


> I'm betting
> that the failure that goetz is experiencing is related to this (as I
> mentioned in my prior reply to him on the subject).  Another reason may
> well be that your build found a different signal.h header file to 
> parse:
> what is the value of SIGNAL_H in your config.log file?

SIGNAL_H='/usr/include/internal/signal_core.h'

configure:11345: result: no
configure:11366: checking what style of signals to use
configure:11397: result: POSIX_SIGNALS
configure:11400: checking where signal.h is located
configure:11439: result: /usr/include/internal/signal_core.h

And I do have:

$ grep -i signal config.h
/* Define to 1 if you use BSD style signal handling (and can block 
signals).
/* #undef BSD_SIGNALS */
/* Define to 1 if `ru_nsignals' is member of `struct rusage'. */
#define HAVE_STRUCT_RUSAGE_RU_NSIGNALS 1
/* Define to 1 if you have no signal blocking at all (bummer). */
/* #undef NO_SIGNAL_BLOCKING */
/* Define to 1 if you use POSIX style signal handling. */
#define POSIX_SIGNALS 1
/* Define as the return type of signal handlers (`int' or `void'). */
/* Define to 1 if you use SYS style signal handling (and can block 
signals).
/* #undef SYSV_SIGNALS */
/* Define to `unsigned int' if <sys/types.h> or <signal.h> doesn't 
define */

FX

Re: zsh 4.3.2 bug

[goetz fischer]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

François-Xavier Coudert wrote:

> I just compiled zsh-4.3.2 fine with:

at least good to know :-)

>
>
> CC=cc ./configure --prefix=/tmp/zsh-install --enable-multibyte && make
> && make install
>
> I have the following configuration:
>
> $ uname -a
> IRIX64 xxx 6.5 10060437 IP27 mips unknown Irix
> $ cc -v
> MIPSpro Compilers: Version 7.4.2m

yes, same for me except 7.43.

>
>
> Maybe switching from c99 to cc would to the trick?

nice idea, could it be that easy?
will try it anyway!
thanks!

>
>
> FX

--
ah-consulting.net
Götz Fischer
Senior Consultant
Phone: +49(0)7225/98 98 79
Fax:   +49(0)7225/28 64
eMail: g.fischer@ah-consulting.net
http://www.ah-consulting.net
http://www.ah-webhosting.com



[-- Attachment #2: Type: text/html, Size: 1085 bytes --]

Re: zsh 4.3.2 bug

[Wayne Davison]

On Fri, Mar 17, 2006 at 06:45:53PM +0100, Fran?ois-Xavier Coudert wrote:
> $ uname -a
> IRIX64 xxx 6.5 10060437 IP27 mips unknown Irix
> $ cc -v
> MIPSpro Compilers: Version 7.4.2m

What are you using for awk?  Is is gawk? mawk? nawk? awk?  I'm betting
that the failure that goetz is experiencing is related to this (as I
mentioned in my prior reply to him on the subject).  Another reason may
well be that your build found a different signal.h header file to parse:
what is the value of SIGNAL_H in your config.log file?

..wayne..

Re: zsh 4.3.2 bug

[François-Xavier Coudert]

I just compiled zsh-4.3.2 fine with:

CC=cc ./configure --prefix=/tmp/zsh-install --enable-multibyte && make
&& make install

I have the following configuration:

$ uname -a
IRIX64 xxx 6.5 10060437 IP27 mips unknown Irix
$ cc -v
MIPSpro Compilers: Version 7.4.2m

Maybe switching from c99 to cc would to the trick?

FX

Re: zsh 4.3.2 bug

[goetz fischer]

On Fri, 17 Mar 2006 11:08:26 +0100
"François-Xavier Coudert" <fxcoudert@gmail.com> wrote:

> > The MACHINES file recommends using gcc for building zsh, but we rely
> > on other people's reports for getting IRIX to work so I don't have
> > any more detail.  Something very close to 4.3.2 was reported to
> > compile on 6.5.something.
> 
> I think that someone might have been me :)
> 
> I indeed built 4.3.1 (but, as you say, 4.3.2 should be strictly
> equivalent concerning this issue) on  mips-sgi-irix6.5 using GCC 3.3
> (itself using MIPSpro assembler and linker). I does work perfectly
> well as far as I am concerned, without having to use any trick.

thanks for the info but as i said i'm not up to use gcc for system related stuff at all.
i'll give 4.3.1 a try and if it doesn't work i'll stay with 4.2.5.

> 
> FX


-- 
AH Computer-Systeme / ah-consulting.net
Götz Fischer
Senior Consultant
Phone: +49(0)7225/98 98 79
Fax:   +49(0)7225/28 64 
eMail: g.fischer@ah-online.com
http://www.ah-online.com
http://www.ah-webhosting.com

Re: zsh 4.3.2 bug

[François-Xavier Coudert]

> The MACHINES file recommends using gcc for building zsh, but we rely on
> other people's reports for getting IRIX to work so I don't have any more
> detail.  Something very close to 4.3.2 was reported to compile on
> 6.5.something.

I think that someone might have been me :)

I indeed built 4.3.1 (but, as you say, 4.3.2 should be strictly
equivalent concerning this issue) on  mips-sgi-irix6.5 using GCC 3.3
(itself using MIPSpro assembler and linker). I does work perfectly
well as far as I am concerned, without having to use any trick.

FX