Please see #85951 (comment) and #85951 (comment).

Still unclear on how to solve the (apparent) bootstrapping issue.

I don't feel confident enough to say if it's a good / bad idea but this patch:

diff --git a/pkgs/development/libraries/glibc/common.nix b/pkgs/development/libraries/glibc/common.nix
index 0429c7295fb..52fa7191cb7 100644
--- a/pkgs/development/libraries/glibc/common.nix
+++ b/pkgs/development/libraries/glibc/common.nix
@@ -203,7 +203,7 @@ stdenv.mkDerivation ({
     configureScript="`pwd`/../$sourceRoot/configure"
 
     ${lib.optionalString (stdenv.cc.libc != null)
-      ''makeFlags="$makeFlags BUILD_LDFLAGS=-Wl,-rpath,${stdenv.cc.libc}/lib"''
+      ''makeFlags="$makeFlags BUILD_LDFLAGS=-Wl,-rpath,${stdenv.cc.libc}/lib OBJDUMP=${stdenv.cc.bintools.bintools}/bin/objdump"''
     }

does fix the issue with the generation of the stub functions and at least confirms what @thefloweringash found. I don't know if there's a better way to somehow line up the binutils tools that are included in the stdenv with other tools like objdump which at that stage get pulled from the bootstrap tools as I understand it.

Alright, @pbogdan's patch solved the issue and the full bootstrap seems to work now. Managed to build opencv, linux_latest, and twelf, all of which failed previously.

@lovesegfault just to confirm - with "bootstrap", you meant building opencv, linux_latest and twelf, not creating new bootstrap binaries, right?

@flokli That's correct.

I'd say let's cook this in staging :-)

Fix for a missing change c10f0a3

Note Python's cffi's tests fail with this bump.

• https://hydra.nixos.org/build/118923568
• cffi repo https://foss.heptapod.net/pypy/cffi/

@FRidh I'm not sure I really understand some of these test failures:

______________________________ test_load_library _______________________________

    def test_load_library():
>       x = find_and_load_library('c')

c/test_c.py:73: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

name = 'c', flags = 2

    def find_and_load_library(name, flags=RTLD_NOW):
        import ctypes.util
        if name is None:
            path = None
        else:
            path = ctypes.util.find_library(name)
            if path is None and name == 'c':
>               assert sys.platform == 'win32'
E               AssertionError: assert 'linux' == 'win32'
E                 - win32
E                 + linux

Why does this code think the platform should be win32? 😕

Most likely because find_library returned None, and that is something that absolutely should not happen.

$ nix-shell -p python3 --pure --run "python3 -c 'import ctypes.util; print(ctypes.util.find_library(\"c\"))'"

functions fine though.

Either we can try and fix the regex ourselves

I don't think this can be fixed by filtering the list by filename. A *.so file is an input for GNU ld which might be a shared library, symlink to a shared library, or a linker script as seen here. ld is now reporting all files and revealing the presence of the linker script. It's likely sufficient to return the first thing that's actually a shared library, but I don't see a way to do that without opening each file and inspecting the contents. An easy way would be to go through the list and return the first one that returns a value from _get_soname.

Actually, we may not have to fix this. In principle we do not support find_library. Packages are required to include hardcoded paths to libraries, thereby circumventing load_library.

numpy also fails, but with "ELF load command address/offset not properly aligned". Too much stripped? https://hydra.nixos.org/build/118901023

$ ldd /nix/store/riqyzfjpskh0qf46f5fjc8ldqbp8aj85-python3.7-numpy-1.18.4/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so 
/nix/store/riqyzfjpskh0qf46f5fjc8ldqbp8aj85-python3.7-numpy-1.18.4/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so: error while loading shared libraries: liblapack.so.3: ELF load command address/offset not properly aligned

Reverting numpy to 1.18.3 did not fix it.

So... we revert binutils for a while again? So far I haven't noticed anything that needs the new version. I'd hope that upstream helps to resolve this within a couple weeks.

Yep, already doing the revert.

Hmm, CVEs are reported for 2.31.1: #63061 so I wonder if there's a version in-between that fixes them but doesn't break python yet.

EDIT: well, we haven't dealt with these in over a year, so perhaps we can just delay a couple weeks longer 😈

The battle to bump binutils rages on! See you guys in the next episode of the binutils Iliad