libc: random panic SIGSEGV when doing parallel builds

[bird]

Two or more parallel builds of mozilla is reported causing random SIGSEGV on an UNI system.

[bird]

Mike thinks this is releated to non-unique temp file names, because he's also seen stuff along the lines of "tmp file is not of a.out format". I know there was changes in the mktemp stuff, so that's the first suspect.

[bird]

We got one more clue, TMPDIR.

This means there are like 3-4 base functions used by gcc, as, emxomf and emxomfld. mktemp is the obviously unsafe one. There is a unused wrapper for it in libiberty, the function used in it's place is using mkstemp and closing the resulting file thus making it impossible to get compflicts unless the IFS is broken. I've tested this pretty well on JFS, HPFS386 and RAMFS without finding any such problems. This means we can rule out anything using the libiberty functions and consentrate on mktemp() calls.

I find these mktemp calls:

1. as.c(875) where we're using mktemp() to find a suitable filename for the intermediate a.out file when -Zomf is specified. This is also using TMPDIR.
2. emxomfld.c(365) where we're creating the responsefile. This should be rewritten to mkstemp and fdopen.
3. ld.c(3874) where we're creating a temporary a.out file. TMPDIR.

ld shouldn't be used. And Mike said he saw some message about that the temp file wasn't an a.out file, so that leaves as.c. I'm pretty much convinced this is the problem.

I will fix these mktemp usages and replace them with mkstemp calls.

(PS. From about 1000000 mktemp calls I get 20 duplicates. So, we are rather unlucky to get mixups here...)

[bird]

Rewritten code using mktemp. The problem should be gone now.