Compilation on Ultrix cc

Compilation on Ultrix cc

[Hrvoje Niksic]

I had problems compiling zsh on Ultrix 4.2 with cc.

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.

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.

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.

These things done, the shell compiles and works well.

-- 
hniksic@srce.hr              |  Student of electrical engineering
hniksic@fly.cc.fer.hr        |  University of Zagreb, Croatia
------------------------------------------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: Compilation on Ultrix cc

[Zoltan Hidvegi]

> 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

Re: Compilation on Ultrix cc

[Zoltan Hidvegi]

[-- Attachment #1: Type: application/pgp, Size: 8004 bytes --]

Re: Compilation on Ultrix cc

[Zefram]

>The patch below should remove the warnings on Ultix with cc.  It removes
>the #ifdef ULTRIX lines from glob.c and always uses Statptr in place of
>struct stat *.  I also removed the #error directive from builtin.c and
>repladed with comething which should generate a syntax error (but I hope
>that noone will see this error).
[...]
> ! #  error there are some unknown limits.  Fixme!
> --- 3535,3541 ----
> !    there are some unknown limits.  Fixme!

Actually the usually preferred way to do #error is thus:

#if SOME_PROBLEMATIC_CONDITION
 #error Fix me.
#endif

This works because K&R preprocessors don't recognise preprocessor
directives unless the # is in column 1.  In this case, they would pass
the "#error Fix me." text through to the compiler, which will barf just
as it would without the "#error".  The advantages of this technique are
(1) ANSI compilers will abort properly, and (2) it makes it clearer
that this is intended to abort compilation.

-zefram