ffmpeg-full binaries do not run on x86-64 NixOS

[DeeUnderscore]

Describe the bug

Binaries in ffmpeg-full (like ffmpeg or ffprobe) from master (41cc1d5) fail to run, with an error like:

symbol lookup error: /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libpthread.so.0: undefined symbol: __libc_siglongjmp, version GLIBC_PRIVATE

Steps To Reproduce

Steps to reproduce the behavior:

1. Try to run bin/ffmpeg from ffmpeg-full

Expected behavior

ffmpeg should identify itself, like: ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers

Additional context

The binaries seem to be linking to libpthread.so.0 from glibc 2.33:

$ ldd /nix/store/qnf36n6013pmf5vpn6qkilaj4ccjd4g9-ffmpeg-full-4.4.1/bin/ffmpeg | rg 'libpthread\.so\.0'
        libpthread.so.0 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libpthread.so.0 (0x00007f09e6f20000)

This is unlike the ffmpeg (non -full) package, which links 2.34:

$ ldd /nix/store/0arxhlwn1w8qfwx4d8i9rd9yh3jmhx4y-ffmpeg-4.4.1-bin/bin/ffmpeg | rg 'libpthread\.so\.0'
        libpthread.so.0 => /nix/store/bvy2z17rzlvkx2sj7fy99ajm853yv898-glibc-2.34-210/lib/libpthread.so.0 (0x00007f458d889000)

I can do something like this:

$ LD_PRELOAD='/nix/store/bvy2z17rzlvkx2sj7fy99ajm853yv898-glibc-2.34-210/lib/libpthread.so.0' /nix/store/qnf36n6013pmf5vpn6qkilaj4ccjd4g9-ffmpeg-full-4.4.1/bin/ffmpeg
ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers
…

and ffmpeg works, but I don't know if some functionality won't break this way.

Notify maintainers

@codyopel

Metadata

• system: "x86_64-linux"
• host os: Linux 5.17.7, NixOS, 21.11 (Porcupine)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.7.0
• channels(d): ""
• channels(root): ""
• nixpkgs: /nix/store/fn03py5wi8d94hqg6m9wvs4672dqxzls-source

[hqurve]

For me (also x86-64 nixos), I experience the following with nixpkgs checked out at 41cc1d5

❯ nix shell .#ffmpeg

  ~srcs/nixpkgs   @41cc1d5d *9                                                                                                                                              19:03:42  
❯ realpath $(where ffmpeg)    
/nix/store/0arxhlwn1w8qfwx4d8i9rd9yh3jmhx4y-ffmpeg-4.4.1-bin/bin/ffmpeg
❯ ldd $(where ffmpeg) | rg 'libpthread'
        libpthread.so.0 => /nix/store/bvy2z17rzlvkx2sj7fy99ajm853yv898-glibc-2.34-210/lib/libpthread.so.0 (0x00007f17c87ea000)
❯ exit
❯ nix shell .\#ffmpeg-full

  ~srcs/nixpkgs   @41cc1d5d *9                                                                                                                                              19:04:17  
❯ realpath $(where ffmpeg)
/nix/store/qnf36n6013pmf5vpn6qkilaj4ccjd4g9-ffmpeg-full-4.4.1/bin/ffmpeg
❯ ldd $(where ffmpeg) | rg 'libpthread'
        libpthread.so.0 => /nix/store/bvy2z17rzlvkx2sj7fy99ajm853yv898-glibc-2.34-210/lib/libpthread.so.0 (0x00007ff3c03ae000)
❯ exit

I suspect you are getting ffmpeg-full from an older commit (likely your system's; Btw, I wish nix-info was somehow able to extract more information about users with flakes) and are experiencing this issue #170897.

[DeeUnderscore]

Considering that my store path is the same as the one you're getting, and is what's output from nix build github:nixos/nixpkgs/41cc1d5d9584103be4108c1815c350e07c807036#ffmpeg-full, I don't think I'm running a different binary.

On the other hand, the same ffmpeg-full does work on another (headless) NixOS system of mine built from the same nixos-21.11 rev, so it does seem to be something with my environment on this machine, which is kind of surprising, because I did not expect that to happen on NixOS.

[hqurve]

To me this should also be impossible, but I have several ideas

• Something with ldd. I don't know how ldd works and if it leaks information into the binary into the output
• You keep mentioning 21.11, however, the commit 41cc1d5 is in unstable
• Something with deployment, some error occurred and the wrong files ended up in the wrong place (highly unlikely). Just a wild guess from me since you mentioned that these machines are remote and I guess maybe you are not using the default binary cache

[DeeUnderscore]

The system is built from nixos-21.11 (8b3398b). This, in theory, should not influence packages I pull from nixpkgs-unstable with nix build or nix shell. The machine that experiences this problem is a laptop that I use X and Plasma on, and everything in that is built against glibc2.33. The main difference between that and the remote machine is that the remote machine is not running X, although it obviously also has a different configuration, with different packages, and is running different services.

I used cache.nixos.org to pull the package, and now I've also rebuilt it from a Nixpkgs checkout at 41cc1d5, with nix build --rebuild .#ffmpeg-full with no errors, so that is probably not the problem.

[SuperSandro2000]

This, in theory, should not influence packages I pull from nixpkgs-unstable

In practice it can especially when LD_PRELOAD is used. This is a known issue not specific to ffmpeg-full. Closing as dupe of #170897