[11250] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: cc (on Sun)

daemon@ATHENA.MIT.EDU (Reid M. Pinchback)
Fri Oct 22 11:32:38 1993

To: jweiss@MIT.EDU
Cc: sparc@MIT.EDU, bug-sparc@MIT.EDU, bugs@MIT.EDU
Date: Fri, 22 Oct 93 11:32:05 EDT
From: "Reid M. Pinchback" <reidmp@MIT.EDU>


> Having cc be a script that tels you to use gcc on the Sun is gross and
> broken.  I'm trying to prepare things like hesiod and moira for public
> distribution, and it's nearly impossible on the Sun.  One of them is
> that the is a C compiler in a sane place.

While unfortunate, this is one of the situations that routine comes up
with VOSAP (vendor-supported architecture).  There is no POSIX or ANSI
committee (yet) handing down stone tablets stating what compilers must
be called nor where they must be located.  Berkeley habits don't
necessarily determine vendor conventions.  Even if we had Sun's C
compiler on the packs, it would be called suncc, not cc.  Anybody who
uses your distribution is going to have to deal with issues like this
on their end, even if you don't want to have to deal with the
inconvenience yourself.  If its difficult for you, its going to be
more difficult for them.

> Not only is it a pain to go
> edit the sometimes multiple makefiles that make assume ${CC}=cc, it
> defeats the purpose of the testing I'm trying to perform by preventing
> me from using the exact distribution that I'm trying to create and
> verify.

With properly created makefiles or Imakefiles this should not be a
problem, but in any case there is a trivial fix.  Put a script called
'cc' in an appropriate sun bin directory that you include in your path
before searching the packs.  Then you can invoke whatever compiler you
want for testing without changing your makefiles.

> Can't we make the script run the invocation of gcc it suggests with a
> warning, or something.

Unfortunately, no... and for much the same reasons as why you would
want a 'standard' compiler name and behaviour.  People writing scripts
and makefiles that may depend on knowing how compiler options are
treated and on what error/warning messages are produced wouldn't
appreciate us introducing our own arbitrary choice of additional
messages and compiler routing.  Having 'cc' not do any compiling is
much safer than having it do something unexpected... particularly with
regards to optimization options, which are in a somewhat different state
in gcc at the moment than in a BSD cc compiler.  Besides, you can't
really use the gcc on the Sun packs without either passing various
command-line options or without setting environment variables to help
it find libraries and include files, so automatically invoking without
knowing what the user is trying to do is not appropriate.  You might
want to look at using the gcc version in the cygnus locker instead,
since it sets some sane defaults that make it easier to use the
compiler as-is, while allowing for resolution of personal
configuration issues and compiler version upgrades.

-----------
Reid M. Pinchback
Faculty Liaison
Academic Computing Services, MIT

home help back first fref pref prev next nref lref last post