generate more symlinks for '.so'-files

ikervagyok commented 7 years ago

Issue description

Every now and then I play GOG/HumbleBundle games in a nix-env. This works astonishingly well in most cases, but every now and then there are some missing libraries. Even though I add the package to my gog.nix file, this doesn't always work as programs may link to foo.so.x.y - and but we only provide foo.so.x.y.z and foo.so.x

Example

I just bought The Stanley Parable on HumbleBundle:

# ./The\ Stanley\ Parable\ Setup
./The Stanley Parable Setup: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory
# ls /lib/libbz2.*
/lib/libbz2.la  /lib/libbz2.so  /lib/libbz2.so.1  /lib/libbz2.so.1.0.6

Resolution

We should ensure within the default pre-install phase that every library file gets all the symlinks to the less explicit version.

So libABC.so.x.y.z would be linked to from libABC.so.x.y, libABC.so.x and libABC.so by default, for every package - no more manually adding '.so'-links for specific packages.

vcunat commented 7 years ago

I'm actually not certain all prefixes are always meaningful. Some distros even intentionally don't provide those, e.g. Fedora.

ikervagyok commented 7 years ago

@vcunat I know that most of the prefixes wouldn't be used , but it would be more flexible for adding new/custom software. Nixos is great at letting Ubuntu/... packages run in a custom environment without modification and this would probably take that compatibility even further.

Could we make it an option just for custom environments, if not for all packages?

Found my broken dependency already 'fixed' in nixos, but resolved for the one package only.

# cd $NIXPKGS; grep -r "ln -s.*\.so\." .
...
./pkgs/applications/audio/bitwig-studio/default.nix:      ln -s ${bzip2.out}/lib/libbz2.so.1.0.6 libbz2.so.1.0
...

Such cases probably should be fixed on a library level, as it leads to code duplication, if it's always fixed individually.

vcunat commented 7 years ago

I see no real reason against (e.g. what it could break), but I'm really unlikely to create a "fix" myself.

My view is that, say for libbz2, the soname is libbz2.so.1, determining ABI compatibility. If a package tries to probe for a longer prefix, I see little to be gained, as that soname is supposed to link to the "newest" version with .1 ABI. (At least in the rare case when you actually see multiple libs at once that provide libbz2.so.1-compatible ABI.)

mmahut commented 5 years ago

Are there any updates on this issue, please

stale[bot] commented 4 years ago

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

Search for maintainers and people that previously touched the related code and @ mention them in a comment.
Ask on the NixOS Discourse.
Ask on the #nixos channel on irc.freenode.net.

Atemu commented 1 year ago

Are we even doing anything in this regard already? If not, I don't think we should. It's up to upstream to provide versioned links.

If upstream is dead and a certain library breaks anything, that specific library should be patched.

NixOS / nixpkgs