While emerging binutils, gcc report obsolete use of mktemp man mktemp BUGS Never use mktemp(). Some implementations follow BSD 4.3 and replace XXXXXX by the current process id and a single letter, so that at most 26 different names can be returned. Since on the one hand the names are easy to guess, and on the other hand there is a race between test- ing whether the name exists and opening the file, every use of mktemp() is a security risk. The race is avoided by mkstemp(3). Reproducible: Always Steps to Reproduce: 1.emerge =sys-devel/binutils-2.15.92.0.2-r7 2. 3. Actual Results: ld sometimes crash in compile/link time Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.200 41102-r1, 2.6.11-gentoo-r5 i686) ================================================================= System uname: 2.6.11-gentoo-r5 i686 AMD-K7(tm) Processor Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 13 2005, 02:42:54) ] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mtune=athlon -march=athlon -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X1 1/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/rc.d /etc/terminfo /etc/wget /etc/env.d" CXXFLAGS="-O2 -mtune=athlon -march=athlon -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://mirror.datapipe.net/gen too ftp://gentoo.mirrors.tds.net/gentoo http://gentoo.mirrors.tds.net/gentoo ftp ://130.207.108.135/pub/gentoo ftp://130.207.108.134/pub/gentoo" LANG="es_AR" LC_ALL="es_AR" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X aalib acpi alsa apm audiofile avi bash-completion berkdb b itmap-fonts bzlib caps cdr crypt ctype curl dio emboss encode erandom esd ethere al exif fam flac foomaticdb ftp gdbm gif glx gnome gnutls gtk gtk2 imagemagick i map imlib jabber jack java jikes jpeg libedit libg++ libwww mad mikmod mmap mmx mmxext mng motif mp3 mpeg mpi ncurses nls nocardbus nocd nptl nptlonly offensive oggvorbis openal opengl oss pam pdflib perl png python quicktime rballs readlin e sasl sdl shared sharedmem simplexml sockets speex spell ssl svga szip tcltk tc pd theora threads tiff truetype truetype-fonts type1-fonts usb userlocales wifi x86 xinerama xml xml2 xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS
http://sourceware.org/ml/binutils-cvs/2001-11/msg00068.html
=================================================================== RCS file: /cvs/src/src/binutils/bucomm.c,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- src/binutils/bucomm.c 2001/09/26 01:55:19 1.10 +++ src/binutils/bucomm.c 2001/11/12 16:17:39 1.11 @@ -233,14 +233,14 @@ #endif strcat (tmpname, "/"); strcat (tmpname, template); - mktemp (tmpname); + close (mkstemp (tmpname)); *slash = c; } else { tmpname = xmalloc (sizeof (template)); strcpy (tmpname, template); - mktemp (tmpname); + close (mkstemp (tmpname)); } return tmpname; }
half the uses are by legacy code which isnt built on linux systems the other half looks like a pain to extract ... and probably isnt worth it ... binutils/bucomm.c defines make_tempname() which uses mktemp() ... make_tempname() is used twice, once by ar and once by objcopy and in both cases, it rarely can be used to take advantage of make_tempname() builds a temp file based upon a filename ... in the case of objcopy and ar, it'll create a temp file in the same dir as the file you're working on. so if you run `ar r archive.a objectfile.o`, it'll create the tempfile in $PWD so this isnt really an issue unless you work on object files / archives in a world writable directory (like /tmp) which, imho, isnt a very common thing if someone feels like writing a patch to resolve this, i'll look it over, but 'fixing' the current behavior doesnt gain anything
*** Bug 105819 has been marked as a duplicate of this bug. ***