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:
dotnet-sdk snap, snap patching RPATH (using patchelf) of
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:
and RPATH in elf is set to
it just can’t find required libraries and loads them from /usr/lib and and has a segfault.
We discussed it with Microsoft guys, and actually don’t know how to deal with it.
Github issue: https://github.com/dotnet/core-setup/issues/5186
I thought the workaround would be somehow tell the snap to patch elf with absolute path to libraries. What do you guys think?
Ping @sergiusens for opinion. Is there something we could do to help?
/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?
We need to add that feature.
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
Thanks, Would be cool to have it in 3.3.
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.
Is there anyway how we can deal with it?
You probably ended up elf patching
RUNPATH instead of
RPATH. If you are using
patchelf make sure you also pass
Ah. Never mind. It’s just me stupid, not deleted LD_LIBRARY_PATH in my .sh file, after experiments.
So yes. It works fine.
Is there any news on that? Can I somehow help with that?
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.
Is there any link to this PR?