Debian Bug report logs - #603603
parallel safe /usr/bin/ar

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: "Barak A. Pearlmutter" <[email protected]>

To: [email protected]

Subject: parallel safe /usr/bin/ar

Date: Mon, 15 Nov 2010 18:44:08 +0000

Package: binutils
Version: 2.20.1-15

Invoking "make -j 12" with a Makefile containing a line like

  libfoo.a: libfoo.a(a.o b.o c.o)

can make the multiple invocations of ar to update each of the .o files
into the .a library in parallel.  This proceeds to fail miserably.

The "right" solution, I think, would be for ar to lock the .a file
using flock(2) or lockf() or whatever, and queue up nicely via
blocking and retrying when there is contention.

If there is some serious efficiency issue associated with this (which
I rather doubt) a switch to disable locking would be appropriate.
That would make ar work in a multicore-build-safe way by default.

					--Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/

Message #10 received at [email protected] (full text, mbox, reply):

From: Matthias Klose <[email protected]>

To: [email protected]

Subject: closing old binutils issue, please recheck with recent binutils

Date: Thu, 18 Dec 2014 18:29:16 +0000

Control: tags -1 + wontfix moreinfo

Closing binutils bug reports reported for ancient versions
of binutils, or for outdated packages built with outdated
versions of binutils.  This doesn't mean that this issue
is fixed, but your help is needed to confirm the issue with
a recent binutils version (currently 2.24.90.20141209-1,
available in unstable).

Please reopen the issue if you think this still needs fixing,
adding all relevant files (including system libraries) in
a tarball attached to the bug report.

Message #17 received at [email protected] (full text, mbox, reply):

From: "Barak A. Pearlmutter" <[email protected]>

To: [email protected]

Subject: reopened + more info

Date: Fri, 19 Dec 2014 09:26:18 +0000

Just sent control@ message to reopen, as this issue remains present.

There is a discussion in make's info pages

  http://www.gnu.org/software/make/manual/html_node/Archive-Pitfalls.html

which reads

  11.3 Dangers When Using Archives

  It is important to be careful when using parallel execution (the -j
  switch; see Parallel Execution) and archives.  If multiple ar commands
  run at the same time on the same archive file, they will not know
  about each other and can corrupt the file.

  Possibly a future version of make will provide a mechanism to
  circumvent this problem by serializing all recipes that operate on the
  same archive file.  But for the time being, you must either write your
  makefiles to avoid this problem in some other way, or not use -j.

A workaround suggested on stackoverflow is to use

  AR := flock make-ar-tempfile.lock $(AR)

to serialize ar.  Ideally ar itself would have an option to take a lock
on the libXXX.a file it is manipulating, and make would pass that option
by default when running in non-serial mode.
--
Barak A. Pearlmutter <[email protected]>
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/

Send a report that this bug log contains spam.