Re: Patch to remove putenv definition from gcc.c

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> Doesn't this mean that collect2 won't work properly with older VAX C?

It looks like it would not be possible to pass options, etc, to collect.
Thus, it would only run with its defualts.

> Wouldn't it make more sense to make libiberty's putenv work on VMS in
> some fashion?  Its putenv is just a wrapper around setenv, so I'm
> guessing that VAX C doesn't have setenv either, and modifying the
> environ[] array doesn't carry down to subprocesses.  [pexecute.c
> assumes fork and exec - does VAX C support those?]

VMS C 5.0 doesn't have setenv but it does have fork and the normal
collection of exec calls.  There may be restrictions on enviroment
variables.  For example, the documentation for getenv states that
`name' is one of the following values:

HOME--Your login directory
TERM--The type of terminal being used
PATH--The default device and directory
USER--The name of the user who initiated the process
Logical name or CLI symbolic name.

In certain situations, getenv attempts to perform a logical name
translation on the user-specified argument.

> I see code in perl5.6 that could probably be stolen (vmssetenv in
> vms.c), although it does not make a whole lot of sense to me...

Neither to me.  It looks like it creates new logical names in the
process table.  I see that perl also replaces getenv.

Your suggestion is a good one but it needs VMS testing to validate.
Any volunteers?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)