Anydesk arm64 #2455
Anydesk arm64 #2455
Conversation
|
@Botspot FYI, the reason this failed https://github.com/Botspot/pi-apps/actions/runs/6423970408 is because you tested as a PR# from the master branch. As the script is written I have it only import any updated app, not script files. That could be changed but its just not how it functions right now. If you want to test a branch in its entirety I suggest selecting the branch from the dropdown and then putting in the app name as I did here -> https://github.com/Botspot/pi-apps/actions/runs/6477319941 |
|
weird... https://github.com/Botspot/pi-apps/actions/runs/6477319941/job/17587322949#step:3:1360 worth investigating, maybe the buster arm64 image ships with corrupted local files or it is being hidden with a pin? |
Maybe Buster's libraspberrypi0 was never made compatible with multiarch. I think I remember something about that, but it's been awhile. |
wait no. I have the debug logging sent directly to the logfile https://github.com/Botspot/pi-apps/blob/master/api#L1772 so it never prints to the terminal. we see it in error reports because the logfile is uploaded but this CI does not cat the logfile. I should add it so that install/uninstall failures cat the logfile in this CI tester. |
|
Same as -> #2198 (comment) We should be encouraging upstream developers to write their applications generically, not conforming to old, unstable, hacky workarounds Anydesk users are encouraged to contact support https://anydesk.com/en/support/contact-us |
Re-opening, as we already tend to take the users' side and implement workarounds for things that vendors should really be responsible for. (Take zoom for example.) |
|
I would like to give this some priority because it is being sought after a lot by the google-searching population. This is THE most popular install-app page we have. And these are the search terms that are responsible. |
apps/AnyDesk/install-64
Outdated
| rpi_arm_userspace="libraspberrypi0:armhf" | ||
| fi | ||
|
|
||
| install_packages https://download.anydesk.com/rpi/anydesk_${version}_armhf.deb libgles-dev:armhf libegl-dev:armhf libpolkit-gobject-1-0:armhf $rpi_arm_userspace patchelf || exit 1 |
There was a problem hiding this comment.
likely unnecessary dependencies
development libraries are nearly never required for a package
control file for anydesk already pulls in egl and glvnd libraries which pull in everything else needed
There was a problem hiding this comment.
these are the libs installed by libraspberrypi0:armhf:
/usr/lib/arm-linux-gnueabihf/libbcm_host.so.0
/usr/lib/arm-linux-gnueabihf/libdebug_sym.so.0
/usr/lib/arm-linux-gnueabihf/libdtovl.so.0
/usr/lib/arm-linux-gnueabihf/libvchiq_arm.so.0
/usr/lib/arm-linux-gnueabihf/libvcos.so.0
I am not sure that the default deps pull those in, at least for armhf
There was a problem hiding this comment.
I am referring to libgles-dev:armhf libegl-dev:armhf
There was a problem hiding this comment.
Without those 2 installed, and then reinstalling the anydesk package and allowing it to pull in deps:
$ anydesk
anydesk: error while loading shared libraries: libGLESv2.so: cannot open shared object file: No such file or directory
There was a problem hiding this comment.
Oh, I get it. AnyDesk should be able to use libGLESv2.so.2 provided by libgles2, instead of specifically needing libGLESv2.so that is only provided by the -dev package.
Looks like this can be fixed with more elf patching.
There was a problem hiding this comment.
hmm... odd
/usr/lib/arm-linux-gnueabihf/libGLESv2.so [libgles-dev](https://packages.debian.org/bookworm/libgles-dev) [armhf]
its not normal that a package uses this library.
those dependencies need to stay then
There was a problem hiding this comment.
Is patching the elf to use the non-dev libs not sufficient?
|
this script needs to force 4K pagesize, as does any other script that uses armhf on an arm64 kernel. and |
|
also it seems to fail to launch if on wayland |
|
I have tested this on piOS bookworm on RPi5 with 4K pagesize kernel on piOS wayfire and it does not function. |
See my comment above: "also it seems to fail to launch if on wayland" strace shows that it is having issues with the Supposedly anydesk runs on pi5 if you switch to X11. https://forums.raspberrypi.com/viewtopic.php?t=366277 |
I tried. |
Maybe that is no longer a thing on Pi5? |
|
and that is indicated by the forum thread given the obvious issues with it not functioning as expected, I think this PR can be closed and we can continue to mark this as an upstream issue. All anydesk needs to do is build their standard client for desktop linux for armhf and arm64 targets. no need for any deprecated broadcom library use |
nice... switching back to wayland in raspi-config now gives me a black screen on boot. good thing this was already a fresh install |
Strange how all these remote-connection tools all use vchiq. Looks like that is the issue with steamlink as well: https://forums.raspberrypi.com/viewtopic.php?p=2174716&hilit=%2Fdev%2Fvchiq#p2174716 |
|
Still going to implement the api changes from this branch |
its the direct interface to the GPU. They were doing it previously for performance reasons and since all the upstream support (eg: KMS) wasn't done yet. Now that is complete and, to my knowledge, that direct GPU access is no longer allowed (hence why the device node is missing). |
Testing required on systems other than PiOS Bullseye 64-bit.
This uses multiarch and some dirty lib symlinking to get Anydesk running on PiOS 64-bit. It avoids installing libraspberrypi-dev:armhf, as that package conflicts with libraspberrypi-dev:arm64.
I doubt Anydesk would successfully open on a system other than PiOS due to missing libs.