* automake.in (handle_merge_targets): Allow parallel install

with forced relink.

1 files changed, 23 insertions, 1 deletions

diff --git a/TODO b/TODO
index 72e86f8a1..5bb791751 100644
--- a/TODO
+++ b/TODO
@@ -1,3 +1,25 @@
+*
+    Alexandre Oliva:
+    > Hmm...  Interesting.  It must have been a side effect of the enabling
+    > of forced `relink' on GNU/Linux/x86.  Anyway, on platforms that
+    > actually require relinking, this problem remains, and I see no way to
+    > overcome it other than arranging for automake to install libraries
+    > before executables, as you suggest.  This shouldn't be a big problem,
+    > anyway.
+    >
+    > A bigger problem could show up if two libraries in the same directory,
+    > one dependent on the other, are installed concurrently.  If relinking
+    > is needed for the dependent library, we have a problem.  It appears to
+    > me that user will have to live without `make -j install', in this
+    > case.
+
+    Alex Hornby
+    > Here's an Automake patch and changelog entry allow make -j install on
+    > such degenerate systems (and Linux with buggy libtool <g>)
+    >
+    > If you install to locations other that bin_ and lib_ then a larger fix
+    > is necessary, but this should fix the 90% case.
+
 * in depend2.am, in specialization case, what if @SOURCE@ is found
   in srcdir?  We can't depend on $<!  We must search explicitly.
   this is a very serious problem!
@@ -296,7 +318,7 @@ Jim's idea: should look for @setfilename and warn if filenames too long
    Doing this requires rewriting macros before generating Makefile.in.
 
 from joerg-martin schwarz:
- -- If Makefile.am contains $(CC), $(COMPILE), $(YLWRAP), .... 
+ -- If Makefile.am contains $(CC), $(COMPILE), $(YLWRAP), ....
     in an explicitly written rule,  you should emit the corresponding
     Makefile variables automatically.