Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plan to be arm64 compatible? #590

Open
jza34 opened this issue Mar 5, 2021 · 3 comments
Open

Plan to be arm64 compatible? #590

jza34 opened this issue Mar 5, 2021 · 3 comments

Comments

@jza34
Copy link

jza34 commented Mar 5, 2021

Hi,
Sadly I can't use Howl with RaspberryPi 4 under Manjaro OS...

First error is:

[lamy@pi ~]$ howl
Failed to load user settings: error in error handling
callbacks: error in 'signal activate' handler: 'error in error handling'

Then I get a another when I compile my init file:

[lamy@pi ~]$ howl --compile .howl/init.moon 
Compiling .howl/init.moon
/usr/share/howl/lib/howl/init.lua:120: .howl/init.moon: bad light userdata pointer

After looking for a solution I guess it is not possible to be under an ARM arch for the moment...

Any advice/tips?

Thanks all

@refi64
Copy link
Contributor

refi64 commented Mar 8, 2021

LuaJIT isn't really actively maintained at this point and the ARM64 support was still pretty buggy, but you could probably try building using the plethora of bugfix patches some distros are shipping.

@jza34
Copy link
Author

jza34 commented Mar 12, 2021

Well, thank you for your advice. Unfortunately I will not go forward with Howl as It seems hard to get it to work and most important stable.
So I have decided to give a try to neovim with some plugins like fzf. It gives me a stable solution even if I already miss Howl...
But, yeah, neovim+fzf gives me what I appreciate the most in Howl, easy file navigation.

I will follow the developpement and try Howl later if it becomes possible to install it with a little compilation or package installation.

Good luck!

@natnat-mc
Copy link

Bit late on the party, but howl compiles and runs on alpine aarch64 (which is another name for arm64), without applying any luajit patches.
It sometimes complains a bit about some missing symbols at runtime, but still keeps running like normal.
The install I have was compiled last year, but the current sources should still work.

Guessing this is either a glibc-related or distro package issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants