Set TMPDIR

[ryandesign (Ryan Carsten Schmidt)]

Clang has a bug (<rdar://problem/12479432>) in which the temporary file names it creates while compiling are predictable (i.e. based on the name of the file being compiled).

Normally on OS X TMPDIR is set to a "random" value, so at least the temp files are unique for each user, so one user cannot DOS another user by creating temp files. But MacPorts clears the environment when it runs, so TMPDIR is empty, and thus defaults to /tmp.

So while compiling, predictable file names are being created in /tmp. This could lead to collisions if multiple compiles are happening simultaneously (user runs two MacPorts processes in two terminals for example). I don't know if that has happened to me, but what does happen constantly is that a compile will fail because a directory already exists in /tmp with the name clang wanted to use for a temporary file. For example ccache failed to build right now with:

ccache /usr/bin/clang -pipe -O2 -arch x86_64 -arch i386 -Wall -W -DHAVE_CONFIG_H -I/opt/local/include -I. -I. -c -o manifest.o manifest.c
clang: error: unable to make temporary file: /tmp/manifest: can't make unique filename: Permission denied

(The directory /tmp/manifest existed because some 3rd-party installer package put it there during installation.)

To avoid these issues, I would like to see MacPorts create a temporary directory inside workpath and set TMPDIR to its location.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

ccache /usr/bin/clang -pipe -O2 -arch x86_64 -arch i386 -Wall -W -DHAVE_CONFIG_H -I/opt/local/include -I. -I. -c -o manifest.o manifest.c
clang: error: unable to make temporary file: /tmp/manifest: can't make unique filename: Permission denied

This llvm bug report describes this error and why it occurs, but does not propose the proper solution which is for clang to use actual random tmp file names using mktemp(3): ​http://llvm.org/bugs/show_bug.cgi?id=13511

To avoid these issues, I would like to see MacPorts create a temporary directory inside workpath and set TMPDIR to its location.

This would be similar to how we're already handling HOME.

[larryv (Lawrence Velázquez)]

Cc Me!

[cooljeanius (Eric Gallager)]

Clang has a bug (<rdar://problem/12479432>)

​OpenRadar link to this issue for those of us without access to the backend of Radar?

[ryandesign (Ryan Carsten Schmidt)]

I am not aware of one, sorry.

[cooljeanius (Eric Gallager)]

Cc Me!

[raimue (Rainer Müller)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[ryandesign (Ryan Carsten Schmidt)]

I think the attached patch is working for me, but I'd appreciate if others would try it and let me know their results, or any comments or improvements on the patch.

[larryv (Lawrence Velázquez)]

There’s a function related to temporary directories at source:trunk/base/src/macports1.0/macports.tcl#L4100​, but I’m not sure anything uses it.

[ryandesign (Ryan Carsten Schmidt)]

I can't find anywhere in MacPorts or ports that uses macports::gettmpdir but if anyone did it seems like it would be doing the right thing even after my proposed change.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

Clang has a bug (<rdar://problem/12479432>) in which the temporary file names it creates while compiling are predictable (i.e. based on the name of the file being compiled).

This is not quite accurate. The temporary file names do have a random suffix. The problem is that when a directory exists in $TMPDIR whose name is the basename of the file being compiled, then clang tries to make a unique file inside that directory instead. So if a source file called manifest.c is being compiled (as is the case with the ccache port), then clang will ordinarily try to make a temporary file $TMPDIR/manifest-XXXXXX (where "X" is a random character) but if the directory $TMPDIR/manifest/ exists then it will try to make a temporary file $TMPDIR/manifest/XXXXXX and this fails if that directory is owned by a different user. And MacPorts-compiled files will be owned by the macports user but other things in $TMPDIR aren't likely to be, which is why this keeps coming up.

Replying to ryandesign@…:

(The directory /tmp/manifest existed because some 3rd-party installer package put it there during installation.)

I found out it's actually the auto-update checking of the DivX software package, which seems to run quite frequently (though it's told to only run weekly). So this directory keeps coming back even after I get rid of it. Of course it's a bug for DivX to be creating predictably-named temporary files, but I can only fix one thing at a time. :)

Replying to ryandesign@…:

I think the attached patch is working for me, but I'd appreciate if others would try it and let me know their results, or any comments or improvements on the patch.

I've been running with this patch for some weeks with no ill-effects. So I'm committing it in r103518.

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

I've been running with this patch for some weeks with no ill-effects. So I'm committing it in r103518.

I’ve been using it since you opened this ticket, and it’s worked fine for me as well.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

Replying to ryandesign@…:

(The directory /tmp/manifest existed because some 3rd-party installer package put it there during installation.)

I found out it's actually the auto-update checking of the DivX software package, which seems to run quite frequently (though it's told to only run weekly). So this directory keeps coming back even after I get rid of it. Of course it's a bug for DivX to be creating predictably-named temporary files, but I can only fix one thing at a time. :)

Reported: ​http://forums.divx.com/divx/topics/numerous_bugs_in_divx_update_checking_on_os_x

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #38386.