David Starks-Browning writes:
>I have gcc in my path, and I had no difficulty. Are you trying to
>accomodate Digital /usr/bin/cc users? Aren't vendor compilers always
>going to be more trouble then they're worth, unless the user is
>willing to specify the right options manually?
In my experience, the vendors' compilers (the ISO/ANSI products,
of course, often only available as an optional package) are generally
of much better quality than gcc, this is especially true for the
Alpha and under OSF/1 (I have also observed this on HP-UX, however
it is not quite as drastic a difference there as on the Alpha AXP
since nowhere does gcc generate as inferior code as on the Alpha);
DEC's compiler is excellent, both from performance POV (compiles
2x faster than gcc on average), aswell as with diagnostics (elaborate,
precise error messages, and detects about everything which might
go awry, in some situations much better than gcc -W -Wall -ansi
-pedantic), and generated code (gcc has always had severe problems
with object code quality on the Alpha and in addition has had some
very bad optimizer bugs on that platform quite recently (2.8).)
Other RISC architectures are not very well supported either, gcc
is still best on i386 and (from hearsay) m68k. This is quite
understandable, given the tight coupling of processor and compiler
on RISC architectures, and the optimal in-house resources the system
vendor has access to (either by contract, or because they developped
the hardware themselves.)
IMHO relying on gcc for portability is not a good choice, and if
Lesstif doesn't compile cleanly with DEC/Compaq's compiler, that's
really an issue that would be worth improving. After all, autoconf
and friends are there to adapt the software package to the local
system environment, not to complicate that issue beyond practicability
(as it is unfortunately often the case with autoconf'd packages on
"non-enduser-mainstream" (read non-linux/non-gcc) systems when the
developper does not have the necessary experience or test environments.)
--mkb
