Closed mclemme closed 11 months ago
Hello @mclemme! Thanks for reporting; Have you tried installing/updating libc? On Ubuntu I believe it is something like this:
sudo apt update
sudo apt install libc6
@javierguzman I'm guessing it is because Ubuntu 20.04 has an older version of libc, see below:
$ sudo apt install libc6
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6 is already the newest version (2.31-0ubuntu9.9).
My guess is it's related to this.
I am a bit puzzled, our pipeline builds using ubuntu 20.04 i.e.
matrix:
include:
- os: macos-12
- os: windows-2019
- os: ubuntu-20.04
We should be on the same page. When we tested this @AlexDygma used Zorin and had the same exact problem though we carried on because on Zorin, official repos did not update to a higher version than 2.31 and 2.34 is from 2021 so it is not that new.
While checking on Zorin we thought about building using ubuntu 18.04 on the CI/CD but Github deprecated the use of that version on 2022, so the minimum version we can build is the one we are using right now.
@javierguzman
That is indeed a bit strange, I just checked the libc version on an Ubuntu 20.04 server I have access to, it says the same:
# apt-get install libc6
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6 is already the newest version (2.31-0ubuntu9.9).
In Ubuntu packages libc 2.31 is shown as the newest available version for 20.04, I can try this from a live USB boot of 20.04 in the weekend just to make 100% sure I can reproduce it there.
My bet is that your live USB boot will have the same problem. I would say the real question is why when we build on Github using Ubuntu 20.04 it uses a different libc different than normal 20.04.
From the stack trace it looks like something in the uiohook-napi package requires a newer version of libc.
It seems like the uiohook-napi dependency ships with a prebuild binary, which was compiled with a newer version of glibc. I'm guessing that Bazecor builds just fine with 20.04 because that particular binary is only ever used at runtime.
Maybe this is the culprit?
prebuild-linux:
runs-on: ubuntu-latest
Good one @mclemme! I think that might be as well. I have just created a PR on the uiohook-napi repository to use ubuntu-20.04 like we have. Let's see if they react accordingly. If they do not merge that change I am not sure what options we would have. We could try an older version to see if that works ok but maybe it introduces some side effects. In any case I will speak with @AlexDygma to see if we can use something else because this library is used only for macro recording and maybe we can avoid it somehow. Last resort could be to make a fork locally and build it at the same time as Bazecor.
This is still not fixed after 1 month. Should I remind you that 20.04 is LTS version that most users that are not using linux for fun are still using?
A workaround is to:
Looks like the PR on uiohook-napi by @AlexDygma was merged. I guess we just need a new release? Any eta on that?
1.3.4 fixed the issue for me on Ubuntu 20.04.
Can confirm that Bazecor-1.3.4-x64.AppImage
also works fine on my Ubuntu 20.04 install, closing this issue as fixed.
Describe the bug When launching Bazecor 1.3.2 the following error is shown (terminal):
To Reproduce Steps to reproduce the behavior:
chmod +x Bazecor-1.3.2-x64.AppImage
./Bazecor-1.3.2-x64.AppImage