Libraries are missing when launching GUI applications #2
Conversation
tunix
requested review from
a team,
AlanGriffiths,
merlijn-sebrechts,
kenvandine,
brlin-tw and
om26er
and removed request for
a team
tunix
added
bug
|
I think this all looks good, the only question I have is __EGL_VENDOR_LIBRARY_DIRS. This might not be ideal for a classic snap, but it could be harmless, just something to think about. |
I think I need this as I remember having issues on a computer with NVIDIA GPU. (intel+nvidia -- prime?) Also, Sergio Schvezov says that changing LD_LIBRARY_PATH is the main cause of the problems. I never heard of RPATH nor RUNPATH. Reading stuff that explains it. |
|
I've had a look through the rust issue tracker after some googling when I saw this PR. It looks like cargo and rust can't be configured to set an appropriate rpath just yet, but there's an issue over there to get it implemented. The alternative, in the meantime until that is sorted upstream, is to look into setting the rpath on the executable after it's been built. There's a utility in the archive called patchelf that can be added to |
|
@diddledan - I replaced LD_LIBRARY_PATH modifications with your suggestion but I'm not exactly sure if I did it right. Unfortunetely it cannot find included libraries. |
tunix
changed the title
|
Sorry for a drive-by comment, but this looks like a job for https://github.com/wmww/snap-out |
Thanks for the suggestion. I added snap-out as a part to the snap and tried adding it into the command chain and into the custom-wrapper script but unfortunetely neither worked. I always got: |
|
Pretty much every export that isn't restricted to alacritty itself is going to cause issues. The wrapper scripts are setting environment variables that will cause breakage seen above. I'd suggest narrowing down the variables to the minimum required (I think I had decent luck with just the two GL vars https://github.com/cjp256/alacritty/blob/snap-core20/extra/linux/snap/snapcraft.yaml#L83), and then perhaps add a tiny patch to alacritty to unset the remainder once initialized. I need to update my intel graphics system to hirsuite, but this works fine for my nvidia hirsuite (shorted out desktop-launch and custom wrapper, no patching of alacritty). |
|
@cjp256 - i tried a lot of different things but none of them have worked. i looked at your snapcraft.yml, removed custom-wrapper, left just the env vars you defined, removed some dependencies etc. And now I get this: libffi is included within the snap as it seems to be required for transparency but it cannot find it unless I pass some other env vars to specify where to look for it. Also I probably will need to add back the custom wrapper because alacritty supports multiple archs and I couldn't find a proper way of constructing the triplet w/o it. |
|
Btw, I found out that if I patchelf alacritty binary during staging, it somehow reverts back all modifications during priming. (checking via readelf at both staging and priming stages: (This is just another thing I tried aside from the things I tried in above comment) |
I'm not entirely clear which binaries you experimented with patching, but some lead directly to problems. E.g. mesa's |
|
@AlanGriffiths - please check this line. Within that block, I tried to change certain parts of the binary to look for libraries within the snap itself and not to the host system. And this is only done for alacritty binary. For GL libraries, I added |
If I read that correctly, you should drop |
As far as I understand, that line replaces RPATH within the binary so that it'll search for GL libraries inside the snap. To my understanding, it should have nothing to do with patching GL libraries in that path. Am I wrong? |
No I am. Sorry. But it still shouldn't be needed. These libs should be found via |
There was a problem hiding this comment.
There are problems with and without this PR.
When launching applications from outside the snap they should not inherit any of the snap's environment.
- There are no layouts (which is good)
- There are environment variables (which is bad)
The default "patch-elf" behaviour should be correct for most things (you shouldn't need to run it "by hand") and avoid the need to set LD_LIBRARY_PATH.
Most of mesa (I think you have more of mesa than likely needed) should be packaged without - no-patchelf. See an example here: https://github.com/MirServer/egmde-snap/blob/78f0dbcc02a56c6a656ca496a6165cf8a527a8e2/snap/snapcraft.yaml#L108
You will likely need to set LIBGL_DRIVERS_PATH and __EGL_VENDOR_LIBRARY_DIRS when launching alacritty for it to run correctly except on 20.04.
The problem this causes is that when launching applications any environment variables set must be restored to what the host environment needs. That presumably needs a patch to alacritty. (Likely unsetting them will be sufficient for most cases, but a more complete solution is https://github.com/wmww/snap-out).
|
I pushed latest changes but still can't make it work. Removed most of the libraries I added and removed most of the env vars. Removed wrapper as well to simplify. The GL drivers are looking for libffi (probably for transparency).
Unfortunetely I don't know how to patch alacritty. I tried snap-out before but don't know if I've done it properly because it didn't work as well. I don't know what else to try. |
Alacritty links to the mesa version from the snap and that needs different environment variables than the native mesa version used by the applications it launches. So at the point where it executes applications alacritty needs to restore the session environment. Unless it already has that capability, this cannot work without patching alacritty. |
|
Hi there, I just read the whole thread but still don't understand how to fix the issue. Is the current release simply not usable? I am on Ubuntu 22.04 using alacritty 0.8.0 from 2021-06-17, but alacritty/alacritty#5064 indicates that the issue with the snap release already existed in earlier releases. Thanks for this app and for your help! |
I think it's more fundamental than that. When launching a third-party application that is not part of Alacritty, the entire execution environment should be restored to what that third-party application needs. Environment variables are just the most immediately-visible thing, but there are many other aspects of the execution environment, and each new version of Linux adds more, such as AppArmor context, resource limits, the capability bounding set, and various inheritable process properties like the ones set by In practice, restoring the execution environment is not actually possible, because many of these process properties are one-way: for example after The other way to get a similar result is to launch applications via an IPC request, so that the terminal emulator itself is running inside the sandbox, but the interactive shell and any third-party applications that it launches are unconfined. This is how terminal emulators packaged as Flatpak apps usually work: they are given the necessary permissions flags to be able to send a request to Obviously, that's a big sandbox hole: it's arbitrary code execution on the host. However, for terminal emulators, I don't really see any alternative: the whole point of a terminal emulator is to use it to run arbitrary third-party commands, and if a terminal emulator packaged with Snap or Flatpak can't do that, then it can't do its job. This appears to have caused at least ValveSoftware/steam-for-linux#9195 and one of several of the reports in flatpak/flatpak#1207. I'm confident that it will also be causing similar issue reports in other random applications that I'm not aware of. Sorry, but expecting the maintainers of all third-party projects to diagnose and support end-user issue reports from a Snap-packaged version of Alacritty that gives them an incomplete or broken execution environment is just not reasonable. If launching apps via an IPC request is not possible in the Snap ecosystem, then something like https://github.com/wmww/snap-out seems like the least-bad alternative.
As a maintainer of third-party software, I would have to say: yes. |
|
Wondering if this is still an issue with release v0.13.1 via #10? I'm not seeing anything come up in the verbose logs: |
|
Indeed, I can't repro this issue at all using the latest revision. I just spent ~15mins or so launching as many different things as I could on a couple of different versions of Ubuntu. I'll close this for now, we can reopen if needed. Thanks for the prompt! |
Fixes #19
Fixes
Issues (WIP)
I'm still working on this to understand why X applications don't work. They work with
sudobtw.