Wrong glibc version used

Hi
I’m having the problem ...2.32-54/lib/libc.so.6: version GLIBC_2.33 not found in bitwig-studio using yabridge (emulates vsts with wine).

I tried to install that version from unstable which didn’t change anything.
Then i tried to update / add glibc from unstable in the bitwig-studio package which broke bitwig entirely (

/home/user/.nix-profile/bin/bitwig-studio: symbol lookup error: /nix/store/73k2knwhv4zzizsjr1g1dqjvzkamx8bd-glibc-2.33-49/lib/libc.so.6: undefined symbol: _dl_catch_error_ptr, version GLIBC_PRIVATE

).

I guess the used glibc version is used from one of the other packages involved but I couldn’t find the right package. bitwig and wine have glib but not glibc.

How can I find out why that version is used?
Where would I have to add or update the dependency?

Thanks :v:

EDIT:
the entire error message:

[2021-09-19 19:57:17.107 indexer info] Could not read metadata for vst64/SoundToys/EffectRack.so com.bitwig.flt.library.metadata.reader.exception.CouldNotReadMetadataException: could not read metadata: com.bitwig.flt.library.metadata.reader.exception.CouldNotReadMetadataException: could not read metadata: Failed to load VST 2 plug-in /home/user/Bitwig Studio/Extensions/vst64/SoundToys/EffectRack.so: /nix/store/jsp3h3wpzc842j0rz61m5ly71ak6qgdn-glibc-2.32-54/lib/libc.so.6: version `GLIBC_2.33' not found (required by /home/user/Bitwig Studio/Extensions/vst64/SoundToys/EffectRack.so)

This may be entirely unrelated, but I had a vaguely similar issue with some packages on a system where I hadn’t run nix-channel --update in a while. Running that got my packages that had been installed with nix-env back into a workable state. Steam still has an old version of glibc, though; I haven’t figured out what the cause is there…

steam right now exports libraries with LD_LIBRARY_PATH, thus the glibc which steam has in it’s runtime dependency graph will be used. In your case, that glibc was older than your system.

It turns out that I had Steam installed via both the main NixOS config and nix-env, and the latter installation “won”, so I guess there’s no surprise that it’d be using the same ancient glibc as the other nix-env packages.