Issue: Dotnet global tools installed thought snaps don’t work
What is global tools?
It’s similar to npm install -g sometool
How do I understand the issue:
While installing dotnet-sdk snap, snap patching RPATH (using patchelf) of /snap/dotnet-sdk/current/sdk/2.2.104/AppHostTemplate/apphost
And patch by itself sets relative RPATH directories.
The issue is: apphost binary is actually copied to user’s home directory while global tool is installed, when dotnet tool install -g dotnetsay executed (or you can specify a path where to install it).
In my case it is: /home/hmvs/.dotnet/tools/dotnetsay
and RPATH in elf is set to $ORIGIN/netcoredeps:$ORIGIN/../../../lib/x86_64-linux-gnu:$ORIGIN/../../../usr/lib/x86_64-linux-gnu
it just can’t find required libraries and loads them from /usr/lib and and has a segfault.
If /snap/<base>/<current> and /snap/<snap-name>/current are going to stick, then absolute paths are fine, all the relative paths were done that way to make the snap global path easier to relocate if it came down to that. Using absolute paths should be fine and solve most of these issues.
@sergiusens Thanks for the reply.
And how we can hint snap to patch binaries with absolute paths instead of relatives? Is there any option for that in snapcraft,yaml?
Any ideas whether it will be implemented or not? If yes, any ideas when it could be?
One more thing: is there a way how we can set environment variable for user? For instance this binaries (global tools) use variable DOTNET_ROOT to find out where dotnet is installed. So we need to have it persistent, not only for dotnet process itself.
This is not a complex feature, we can target this for 3.3
Can we split this out into a different forum topic? This could be designed in different ways and I do not want to pollute this topic or your initial request might go into the bucket of forgotten things
Found related issue with it. Just for the PoC I’ve patched global tool lets say dotnet-lambda with absolute rpath.
So after the patch it didn’t segfault and shows help.
But I got another issue: this tool runs zip command which as I understand uses RPATH from the parent process and loads libc and others libraries from snap instead system one. So zip is crashing right now.
I am so sorry I dropped the ball on this. I will see if I can get to it… there’s a major refactor PR going on that would need to land first to apply the change from solid grounds which I will gate on though.