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.
