RPATH in ELF that can be moved across system

snapcraft
1

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.

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?

1 Like
2

Ping @sergiusens for opinion. Is there something we could do to help?

3

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.

1 Like
4

@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?

5

We need to add that feature.

1 Like
6

Any ideas whether it will be implemented or not? If yes, any ideas when it could be? :slight_smile:

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.

7

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 :slight_smile:

3 Likes
8

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?

9

You probably ended up elf patching RUNPATH instead of RPATH. If you are using patchelf make sure you also pass --force-rpath.

10

Ah. Never mind. It’s just me stupid, not deleted LD_LIBRARY_PATH in my .sh file, after experiments.

So yes. It works fine.

11

Hi, @sergiusens.
Is there any news on that? Can I somehow help with that?

12

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.

13

Is there any link to this PR?

14

Here it is
https://github.com/snapcore/snapcraft/pull/2709