[1297] in Release_7.7_team
Re: sun compiler logistics
daemon@ATHENA.MIT.EDU (Alex T Prengel)
Thu Jun 4 14:38:31 1998
To: Greg Hudson <ghudson@MIT.EDU>
Cc: ajfox@MIT.EDU, release-team@MIT.EDU, miki@MIT.EDU
In-Reply-To: Your message of "Thu, 04 Jun 1998 13:56:33 EDT."
<199806041756.NAA18449@small-gods.mit.edu>
Date: Thu, 04 Jun 1998 14:38:23 EDT
From: Alex T Prengel <alexp@MIT.EDU>
>> 4. Using /afs/... paths vs. /mit/.... paths in LD_LIBRARY_PATH
>Very ugly problem. Using /mit paths will produce binaries that won't
>run if the sunsoft locker isn't attached, whereas using /afs/... paths
>will produce binaries which won't run if the sunsoft locker isn't in
>that particular AFS location. I would really be much happier if we
>could find a way to make the compiler use static libraries.
Well, the standard -Bstatic switch produces static binaries, but it's not
the default. I don't think it's a good idea to change the way a standard
vendor compiler works... also, of course, it will make the binaries much
larger. Is there really a significant risk of things moving around in afs?
If yes, then I'd recommend using /mit/... and the short attach-and-run
script method we are advocating now.
There is still the problem of users wanting to use dynamic linking
with newer compilers that are not yet the default- they would have
to include something version-specific in any case... maybe the thing
to do is explain the issues in a README and say "proceed at you own
risk..."?
>> 5. Do we want to keep "suncc"?
>Probably not.
Oookay- then it has to come out of the current attach-and-run script, and
be replaced by cc. We might get complaints...
A.
