From: Peter Gerwinski <peter AT agnes DOT dida DOT physik DOT uni-essen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: I/O problems
Date: 5 Apr 1998 22:48:00 GMT
Organization: Universitaet Essen
Lines: 33
Message-ID: <6g91n0$goe7@mx2.hrz.uni-essen.de>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980405165903 DOT 6401A-100000 AT is>
NNTP-Posting-Host: agnes.Dida.Physik.Uni-Essen.DE
User-Agent: tin/pre-1.4-971123 (UNIX) (Linux/2.0.33 (i486))
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> 
> If you want, I can mail you patches for the functions that generate 
> temporary file names which should solve these problems.  These patches 
> were submitted for DJGPP v2.02 a couple of weeks ago.  I have never 
> tested them in the setup like yours, though.

While the patches fixed `mktemp()' they did not solve the
problem directly (but "only" pointed me to the right direction:-):

When `gpc.exe' (or `gcc.exe' for that matter) chooses a new
temporary file, it chooses one base name (say, "ccaaaaaa") and
appends several suffixes to it ("ccaaaaaa.i", "ccaaaaaa.s", etc.).

Now a second instance of `gpc.exe' starts work and tries to
choose a new temporary base name.  Since no file "ccaaaaaa"
(without suffix) exists, `mktemp()' has no problems returning
the same pattern again.

I could solve the problem by telling `gpc.exe' to create a
dummy file "ccaaaaaa" seen by `mktemp()'.

Another possible solution would be to tell `mktemp()' to look
out also for "ccaaaaaa.*" and not only for "ccaaaaaa".

Again:  Thanks a lot for your big help!  :)

    Peter
-- 
    Peter Gerwinski, Essen, Germany, free physicist and programmer
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997
PGP key fingerprint:  AC 6C 94 45 BE 28 A4 96  0E CC E9 12 47 25 82 75
                Fight the SPAM! - http://maps.vix.com/