[Bug ada/49097] gnatbind link fails to find version_string, potential ranlib concurrency problem

["amylaar at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49097

--- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2011-05-21 19:23:15 UTC ---
(In reply to comment #1)
> Created attachment 24317 [details]
> untested patch

Looking at the patch, I agree that it should fix the problem.

> Please see if this patch (untested) fixes the problem for you.

I have tested the patch, and no such link problems with gnatbind were evident.
However, that doesn't really mean much.  I also ran a test yesterday for
mainline + patch for PR46500, and the problem was not evident.
These things are fickle as they depend on load.
We can get a bit more detail when we look at near misses.  I.e. if the
dependency is known to make, it should try to arrange the build so that
some commands can be run between the ranlib and the link that uses the
affected library, and conversely it should cease to prefer to run the link
in preference to other commands with equal dependencies.

Looking for instances where the ranlib use on libcommon.a appears later than
ten lines before the gnatbind link in the logfile, we find for yesterday's
mainline build:
 distance -2 (i.e. the link was launched before ranlib, but the link succeeded,
  presumably because the link finished reading the library before ranlib
  altered it): i686-solaris2.9
 distance 1 (i.e. gnatbind link follows immediately after ranlib on
  libcommon.a): arm-elf, avr-elf, bfin-linux-uclibc, frv-linux, hppa64-hpux11.0
--enable-sjlj-exceptions=yes, hppa64-hpux11.3, mipsisa32r2-linux-gnu,
mn10300-elf, powerpcle-eabi, sh-rtems, vax-linux-gnu, x86_64-freebsd6,
x86_64-mingw32 --enable-sjlj-exceptions=yes, x86_64-pc-linux-gnu
--with-fpmath=avx, x86_64-w64-mingw32, xtensa-linux
 distance 3: powerpcle-eabisim
 distance 7: x86_64-netbsd, xstormy16-elf
 distance 8: i686-cygwin --enable-threads=yes, pdp11-aout
 distance 9: ia64-elf, ia64-hp-vms, mips-wrs-vxworks

For yesterdays's build of mainline + patch for 46500:
 distance 1: avr-rtems, crisv32-linux, i686-mingw32crt, ia64-hpux,
powerpc-darwin7, powerpcle-eabi, powerpc-linux_paired, rs6000-ibm-aix4.3,
rs6000-ibm-aix5.1.0, sparc-sun-solaris2.9, x86_64-freebsd6, x86_64-mingw32
--enable-sjlj-exceptions=yes
 distance 2: x86_64-pc-linux-gnu --with-fpmath=avx
 distance 8: i686-cygwin --enable-threads=yes
 distance 9: mep-elf

For yesterday's mainline + your patch:
 distance 4: x86_64-apple-darwin, x86_64-netbsd
 distance 5: i686-solaris2.9, powerpcle-elf, x86_64-w64-mingw32
 distance 8: x86_64-elf --with-fpmath=sse
 distance 9: alpha64-dec-vms, alpha-freebsd6, alpha-netbsd, rs6000-ibm-aix4.3,
spu-elf

For the above distance 4 cases we find gcov and gcov-dump as being built
between the ranlib and link (the gcov-dump rule has a backslash so it counts
as two lines).

For i686-solaris2.9 / x86_64-w64-mingw32, it also dovetails the libbackend.a
ranlib run there, while for powerpcle-elf, it builds gnat1 before gnatbind.
Overall, I think we have evidence that the dependency has an effect on the
build order.

>  If so I'll
> commit it as obvious.  This missing dependency was pre-existing, but maybe it
> didn't matter before.

Agreed.  The other used libraries tend to be built much sooner.