[1295] in Release_7.7_team
sun compiler logistics
daemon@ATHENA.MIT.EDU (Abby Fox)
Thu Jun 4 12:59:35 1998
To: release-team@MIT.EDU
Cc: miki@MIT.EDU, alexp@MIT.EDU
Date: Thu, 04 Jun 1998 12:59:28 EDT
From: Abby Fox <ajfox@MIT.EDU>
Alex would like input on the logistics for changing the sun compiler
defaults. Does it make sense to do this over email, or should we make
it an agenda item?
--Abby
------- Forwarded Message
Date: Wed, 03 Jun 1998 11:45:27 EDT
From: Alex T Prengel <alexp@MIT.EDU>
To: ajfox@MIT.EDU
cc: alexp@MIT.EDU
Subject: further issues pertaining to Sun compilers (somewhat long-winded :-)
1. When to change? Users might expect a compiler change with the new
Athena release, but these are in a locker and not tied to the
release. I am inclined to try it sooner, to see if there are any
problems/test. Does that make sense?
2. The latest Sun compiler CD, V5 N1, which I am proposing to make the
default, also has pc, f90 and CC compilers. Does it make sense to also
have attach-and-run scripts for them in the release, like cc and f77 now?
3, Testing- since the compilers are not in the release, there is no easy
way to test them "off-line". The V5 N1 compilers have been installed for at
least 4 months, but users have to do "add -f sunsoft_v5.1" to use them now.
I have no idea if anyone has actually been using them... on the other hand,
switching the default is very easy- all that has to change is the
/afs/athena/software/sunsoft link... so we can restore the status quo very
easily if something bad happens. The new compilers also use a domain-based
key, which does not require connecting to a license server. This will
probably be for the better but hasn't been tested in volume use yet.
4. Using /afs/... paths vs. /mit/.... paths in LD_LIBRARY_PATH; I have
been using /mit/... but sometime ago jhawk pointed out that if a user
compiles a FORTRAN binary by just doing f77 foo.f, the binary won't work
unless the Sun compiler locker is attached at runtime. This can be done
by writing a short wrapper script like:
#!/bin/sh
attach -q sunsoft
exec myprog.real $*
(as is recommended now). But this is an added complication, and if a user
wants to use a compiler that is newer that the current default, say in a new
sunsoft_v5.2 locker, then he would have to do:
#!/bin/sh
attach -q sunsoft_v5.2
exec myprog.real $*
Which is even trickier- if he forgets and leaves it as "attach -q sunsoft",
he will potentially be using an older FORTRAN library than the one that
comes with the compiler he is using- this is probably a bad thing. I
would tend to agree with jhawk that we should change to /afs/... paths.
This shouldn't break anything already out there and will automatically
access the libraries that came with the compiler at runtime. Do folks agree?
Note that this in turn implies that we could never delete any compiler
locker we have installed, since binaries would have hard-wired paths to
that specific version- and old binaries would not be using the "newest"
libraries at runtime, but rather exactly the versions that came with the
compiler they were built with.
Another thing worth noting is that if we want to let users use newer
compilers that the current default, we have to do something like this
(point to version-specific libraries at runtime). My personal thought is
that we should accept this, and agree that we will keep all the compiler
lockers we have installed.
5. Do we want to keep "suncc"? At this point, I think it's purely historical,
yet dropping it now might break old existing Makefiles. Do we want to keep
it around forever? One slight advantage is that it avoids having to include
the -f switch if a user wants to use a newer compiler locker than the current
default; however this only applies to cc (since we never had "sunf77"). Is
it worth keeping?
Alex
------- End of Forwarded Message
