Open benjaminedwardwebb opened 1 year ago
I know dmenu-rs does work on Arm64, as I've had it running on a RockPro64. Just compiling as normal on an aarch64 host should work just fine (cargo/clang picks up target automatically).
As for cross-compiling, there are at least two places where this needs changed:
@benjaminedwardwebb Do you know how cross compilation for rust projects work on other nixos projects? If I have time (it wouldn't be until late Jan) I could work on (1) porting the remaining C to Rust to simplify the build system and (2) use the new libloading crate features to make plugins run through dynamic linking.
Do you know how cross compilation for rust projects work on other nixos projects?
Not yet -- I'm relatively new to NixOS, and even newer to rust -- but I'm trying to figure out what's required.
I believe nix has good support for cross-compiling both C/autoconf-style builds as well as rust/cargo-based builds, and I think it should be possible (if a little more complicated than usual) to get it working for a mix of the two.
It helps a lot to know that there is nothing about the project itself that blocks it from cross-compiling to an aarch64 system.
(1) porting the remaining C to Rust to simplify the build system
By "remaining C" do you just mean stest
?
(2) use the new libloading crate features to make plugins run through dynamic linking.
That sounds awesome.
FYI, what I added to nixpkgs only includes the default plugins and has this disclaimer about it. I wasn't able to figure out how to integrate nixpkgs' rust tooling with a Cargo.lock
file that is generated during an earlier phase of the build (again, probably possible, but wasn't straightforward for someone as green as me).
By "remaining C" do you just mean stest?
Yes
I wasn't able to figure out how to integrate nixpkgs' rust tooling with a Cargo.lock file that is generated during an earlier phase of the build.
I'm unsure if this is actually required, as Cargo.lock will get regenerated. Then again, having to call cargo multiple times certainly causes issues. Yet another thing that would be fixed if I went the libloading route.
I tried building dmenu-rs on my aarch64 linux machine locally (not cross-compiling).
I hit a few compiler errors that appear architecture related. They seem caused by the fact that the type of c_char
varies as i8
or u8
depending on the system.
My vague impression is that these issues aren't local to my machine and that they can be fixed by using a type that properly varies by system. However, I'm not sure how to do that for the fontconfig
-related constants (e.g., FC_FAMILY
). How C and rust interop is way beyond my knowledge of either language.
The errors are attached as log files. Any ideas?
I generated make.log
by running make > make.log 2>&1
on f597d4e5
of dmenu-rs. This commit adds a nix-shell
-based development environment for dmenu-rs on top of master
.
I generated nix-build-dmenu-rs-aarch64-linux.log
by running NIXPKGS_ALLOW_BROKEN=1 nix-env -iA dmenu-rs -f . > nix-build-dmenu-rs-aarch64-linux.log 2>&1
on 84edcb0b
of nixpkgs checked out locally.
Both commands were run on a system with
uname -a
Linux vm-lamu 6.0.11 #1-NixOS SMP Fri Dec 2 16:43:18 UTC 2022 aarch64 GNU/Linux
so these issues may be related to my nix setup, but my hunch is that they aren't.
Once #47 is merged, I'll fix #46, and #48. Then, I'll get this fixed.
I'd love to be able to use
dmenu-rs
onaarch64-linux
hosts.On the surface this seems doable given that
aarch64-linux
architectures are supported as tier 1 platforms bycargo
. However I'm not sure if there may be some difficulties due to other parts of the build. My extremely naive approach of slapping--target=aarch64-unknown-linux-gnu
after every invocation ofcargo
in themakefile
didn't work. :)I'm filing this issue in case anyone has any tips, ideas, or pointers on how to do this.