I can find various efforts online to cross-compile for Raspbian (Raspberry Pi) but none of the solutions work anymore (as of May 2022). Installing Crystal on Raspbian seems equally unachievable. Are there any more recent and successful attempts to solve this problem? Can anyone offer any solutions in this regard?
1 Like
I have a old-ish setup of crystal on the PI but have not tried to update to a recent version.
The general process was this: arm - How do I install crystal-lang on rapsberry pi? - Stack Overflow
I don’t know if you tried that or if it still works at all.
In any case I will probably have to update my setup soon too, so if you could report back with your eventual findings, that would be great :)
That was one of the first things I’ve tried – and it doesn’t work anymore. Thanks!
I did this in 2019, I don’t see why it would stop working
https://hugopl.github.io/2019/04/28/Crystal-on-raspberry-pi.html
Reading again after 3 years I see that the steps I describe could be simplified a bit.
UPDATE: Now I remember that the small static library that deal with signals was ported to Crystal, so there’s no need to compile it.
I am using multiarch/qemu-user-static docker container to build Arm binaries. This method is slow but works for me.
Thanks! I’ve managed to compile a relatively simple Crystal program on my Pi!
One question though: the cc line that crystal build generated included a reference to -L/usr/local/Cellar/libevent/2.1.12/lib which is obviously on the source computer, not on the Pi. But compilation worked nevertheless :) Why didn’t it complain that it couldn’t find libevent there? Is this what you meant by “the small static library that deals with signals”? If it’s now part of Crystal, then why was it added to the cc command line?
The -L option specifies locations where the linker should look for libraries. If the path doesn’t exist, but the library is found elsewhere, there is no error.
In fact, the generated cc link command string exists others redundant output,
e.g. following code exists duplicated -lpthread, i consider it is unnecessary, but link is working! i guess because cc is smart enough to not link pthread twice.
cc crystal_hello_world.o -o crystal_hello_world -rdynamic -L/home/zw963/Crystal/bin/…/lib/crystal -lz command -v pkg-config > /dev/null && pkg-config --libs --silence-errors libssl || printf %s '-lssl -lcrypto' command -v pkg-config > /dev/null && pkg-config --libs --silence-errors libcrypto || printf %s '-lcrypto' -lpcre -lm -lgc -lpthread -levent -lpthread -ldl
-lpcre -lm -lgc -lpthread -levent -lpthread -ldl
@straight-shoota , is this on purpose?
I suppose it is kinda on purpose, yes. We’re adding the link annotation for pthread in boehm.cr to ensure a specific link order. This duplicates with the “natural” link annotation in the respective C bindings.
It works though, and the linker doesn’t complain. So I don’t see much reason to clean it up. We could probably do that in the compiler before forwarding the arguments to the linker. It would probably work as well, but it’s not worth the trouble when there is no real disadvantage here.
1 Like