The resulting binary prints “no version information available” for one of the shared libraries it needs. It doesn’t complain about any other library. What should be the next steps?
You’re gonna need to give us more to go off of here.
I can tell you that the error message you’re seeing is not a “standard” error message for any dynamic linker used on any system that Nix supports - so whatever is crashing is crashing at runtime in some logic that your executable holds.
For starters, “what were you building?”, “what version of nix?”, “what version of Nixpkgs?”, “what platform/arch?”, etc.
The executable is built for RHEL8 and libpq.so.5 (that’s Postgres) is the library which shows the message. I am on the latest nixpkgs unstable. I saw some threads (e.g.libpq.so.5: no version information available - CentOS) that RH builds it differently. The question is how to replicate that (build with the symbol versioning) with nixpkgs or should I try to use libpq from RHEL8 as well?
There was also this thread (Re: Shared PostgreSQL libraries and symbol versioning - Mailing list pgsql-hackers : Postgres Professional).
Finally, despite the message, the executable seems to be working (the interaction with postgres is small part of its functionality), but it is unclear if it is completely happy with the libpq from nixpkgs.
RHEL maintains forks of popular projects that it uses as the default installs. These are publicly available, so personally what I did when using Nix on RHEL was pull their patches and “Nixify” the build.
Symbol versions can be controlled with link flags, and ld version scripts. These are easy to add/generate, and can be added to builds.
I did this for ~200 libs on RHEL last year at work.