Libpthread.so.0 Undefined Symbol H_errno Version Glibc_private
Fairy Dawdy
disregard what I stated and go to install Ubuntu 19. This page states that I was running on Ubuntu 19 and I was. This page should work fine for Ubuntu 19 but there could be issues if you install with Ubuntu 20. You might want to read this link for installing Ubuntu 20 on a Pi4. There were issues with hdmi monitors on Ubuntu 20. They are explained and resolved in the Ubuntu 20 install procedure. I would install Ubuntu 19 following the Ubuntu 19 procedure.
Just to close the circle, I found that I couldn't run Rosetta and Einstein at the same time on a Raspberry. Have tried Ubuntu but now gone back to Raspian and running Einstein only. Reasonably happy with results.
There is an unofficial aarch64 BRP4 app that the Pi3 and Pi4 can run, compiled and optimized by user N30DG-ARM. To use it you would need to use BOINC's anonymous platform mechanism. It won't work under Raspbian even if you set the boot parameter to arm_64bit=1 as Raspbian has a 32 bit userland. It will work under Raspberry Pi OS (64 bit) as its basically Debian for aarch64 with tweaks for the Pi. The Rpi foundation state its a "beta" version but I updated all my Pi4's to it some months ago and haven't had an issues so far. Ideally you'll need a 2GB Pi because the app uses a bit more memory than the official one (about 30Mb per task) but its almost twice as fast as the official app.
If you are interested in going down this path let me know and I will see if I can dig out some links to both Raspberry Pi OS (64 bit) and the BRP4 app for you. The Rpi OS link is in a forum post on their website and the BRP4 app is in a couple of forum posts on here.
That looks like an incompatibility between glibc versions. Not sure when it happened but h_errno got renamed to __h_errno so at a guess your program (or a library it uses) was compiled against the older version of glibc and needs access to that internal symbol. Recompiling under Stretch should fix it.
Looking through some notes it was around 2015 so Jessie probably has the older glibc and Stretch will be using the newer one.
The v1.06 application is built in 2013, so wouldn't it break on most systems since 2015 ...?
In my preferences I have enabled "Run Linux app versions built with LIBC 2.15" to tell I'm running on "more recent" libcs, I don't see anything better that could be configured there? Can I somehow tell Einstein not to send me tasks for that v1.06 application?