X-Authentication-Warning: hp2.xraylith.wisc.edu: khan owned process doing -bs
Date: Thu, 6 Jan 2000 11:10:27 -0600 (CST)
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: protoize for djgpp
In-Reply-To: <Pine.SUN.3.91.1000106120254.20220I-100000@is>
Message-ID: <Pine.HPP.3.96.1000106110612.26216W-100000@hp2.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 6 Jan 2000, Eli Zaretskii wrote:

> Sure.  Except that on Unix, GCC is generally not moved like that.

Not so in our environment. We have a fleet of few thousand machines
where users pick up tarballs and may install to specific directories
to maintain multiple version (eg., install to /usr/local/gcc-2.95.2
instead of build prefix, say /usr/local). I do agree that it's not 
common in other environments.

> 
> > I'm going eventually retrofit the "relative path" lookup to it, and
> > then it should be relocatable as well.
> 
> DJGPP now has a feature to satisfy these needs: the special prefix
> "/dev/env/FOO" is transparently replaced at run time by the value of
> the environment variable FOO, just before the file name is passed to
> the OS.  Since the DJGPP header files are at fixed places relative to
> the DJDIR variable, you simply need to compile with
> --prefix="/dev/env/DJDIR", it will work anywhere.

Neat. 

> DJGPP has a working "link" in the library (which simulates a hard link
> by copying).  But "rename" will also work, of course.

That's why I want to get rid of renaming via (1) link old to new, and (2)
unlink old. It sounds like a good trick, until you run into systems where
hard links are not supported (doesn't work), or emulated by copying 
(inefficient).

> Yes.  However, if FD can ever be stdin or stdout connected to the
> console device, please use this:
> 
>   #ifdef O_BINARY
>   if (!isatty(fd))setmode (fd, O_BINARY);
>   #endif

protoize reads files, so not an issue in this case.

Regards,
Mumit