Auto-detect ld v2.24 and disable USE_BINARYBUILDER_LIBUV.

[staticfloat]

Potential solution to #31555 (comment). I am trying to avoid having to fully parse the version number as that's complex in Make, and I don't even know what the proper bounds on invalid ld versions are (I just know that 2.24 doesn't work, and 2.26 does work)

[vchuravy]

This looks fine to me, but I also am not sure I am qualified to review.

[staticfloat]

After playing around with this, I really don't like it. For this to work robustly, we need to:

• Reliably discover ld version, which can be somewhat annoying, as people sometimes patch the version strings to say something like 2.24~ubuntu or whatever, and writing the parsing in make is no fun.
• Check every single time you invoke make (including sub-makes), which quickly gets annoying if we spam out messages all the time, but is also annoying if it silently changes behavior. (This could be addressed by implementing an environmental data caching system in make, but that seems slightly ridiculous to me)

The fundamental problem here is that apparently ld static output is not forwards-compatible, so ld v2.24 can't use static libraries generated by ld v2.26. That's a bit of a problem for us, and the potential solutions are varied:

• Change BB to use an older ld. This sounds attractive at first, until we realize that means that we lock ourselves out of fun things like assemblers that understand AVX, and it can get difficult to build newer projects with very old as and ld.
• Change Julia to link dynamically against everything, just completely forgo static linking at all.
• Don't use BB on these libraries unless explicitly asked (e.g. these guys must be opt-in)
• Ship a compatible binutils with Julia when using BB versions of these projects. We're already shipping dependencies, why not start shipping bits of toolchain as well?

[vchuravy]

I think:

Don't use BB on these libraries unless explicitly asked (e.g. these guys must be opt-in)

Is the right conservative option.

[StefanKarpinski]

• Ship a compatible binutils with Julia when using BB versions of these projects. We're already shipping dependencies, why not start shipping bits of toolchain as well?

I like this option. If operating systems can't be trusted to not be broken junk (and they can't, unfortunately), then we need to take over that responsibility and ship stuff that isn't so broken.

[staticfloat]

As a side note; it appears that there are other, subtler bugs that can occur even just when combining old GCC versions (like our GCC 4 shard) with new binutils (example). I think I'm going to need to build a binutils per GCC shard, we'll just use a binutils close to that GCC version.

This compiler multiversioning mess is getting out of hand, so I have written up some thoughts about what the problems are, how we're solving them, and I've started rebuilding our system images to try and address these issues.

[owainkenwayucl]

Just a note that this is also an issue on RHEL 7.x.

$ ld --version
GNU ld version 2.25.1-32.base.el7_4.2 
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.