Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Compilation on Ultrix cc



> I had problems compiling zsh on Ultrix 4.2 with cc.

Which version?

> 1. configure determined that the compiler is non-ANSI, which is true enough,
> but ansi2knr is still unnecessary since all it does is converting the
> function declarations to ANSI-style, and the cc can handle them.

No. ansi2knr converts ANSI-style code to K&R style code.  Ultrix cc does
not understand ANSI.

> 2. In several places the name of a variable is the same as the name of a cpp
> macro. The newer cpp-s ignore the variable, whereas the Ultrix cpp gives a
> warning, but still makes the substitution with an empty argument. This
> prevents the compilation of builtin.c (because of iword macro/variables) and
> zle_tricky.c (because of nonempty macro/variables). The solution is to
> rename either the macro or the variables in both cases. Note that
> zle_tricky.c uses both forms of nonempty.

Could you be a bit more specific here?  Which macro and which wariable
causes the problem?  If you have a fix please send the patch to the list.

I admit that Ultrix cc does not work with beta17.  It uses some very stupid
and broken cpp.

c89 is probably capable to compile zsh but I'll check this tomorrow.  And I
did compile zsh with gcc on Ultix 4.2.

> 3. glob.c contains the things that make Ultrix compiler happy wrapped within
> #ifdef ULTRIX. However, the Ultrix cc defines only ultrix (lower-case),
> which is why a %s/ULTRIX/ultrix is welcome in glob.c. Without it, glob.c
> will not compile.

It seems to me that the code in the #ifdef ULTRIX part can be used on all
systems.  Does anyone know why is there this ULTRIX check?  We can define
the Statptr type on all systems and use it instead of struct stat *.  Or is
there some other compiler which does not like this?

Bye,

Zoltan




Messages sorted by: Reverse Date, Date, Thread, Author