I’m trying to run DCSS on a Kindle so I can play on an eink screen out in the sunshine . I set up a Debian 11.9 armhf chroot environment and I followed the build instructions here. Everything seemed to build OK (some info-level outputs but no errors) but when I run the game with ./crawl I get the error message: Lua execfile error (dlua/sanity.lua): /home/crawl/crawl-ref/source/dat/dlua/sanity.lua:4: No map found for Zot:$.
I checked on the file mentioned in the error (sanity.lua) and it appears to be failing at a step that checks for the existence of maps for all of the game’s locations. As a test I commented out those lines and I tried ./crawl again. This time the executable runs OK and I could navigate the menus. But when I try to start a new game after character creation I get the error Fatal error: No temple of size 8.
Clearly there is an issue with map information. Not really sure what to do next, any ideas?
armhf is not a widely used compilation target but I believe people have succeeded with this in the past (here’s a reddit post), so it should in principle work. The errors you report are a bit puzzling though because they suggest that dat (where the maps live) is being loaded. I wonder if it’s the map cache location that’s not working? I think on linux this should normally live in ~/.crawl/ – can you confirm whether this exists, is writeable, is a directory, etc? If I’m right about the location and the map cache was created, it should be a subdirectory of this named des (i.e. ~/.crawl/des/). It’s possible that a chroot just wouldn’t have home directories set up properly without manual intervention. Edit: from talking to another dev who uses linux, if this is a normal in-repository build what I first thought is wrong. Rather, it would be trying to put the save directory right in the source directly, so you’d be checking instead for ./saves/des/.
As a test I commented out those lines and I tried ./crawl again. This time the executable runs OK and I could navigate the menus
If the above doesn’t get anywhere, could you report what happens when you hit ctrl-p at the main menu? Also what you see with ?V (which should give the version info + some diagnostics, including the save path).
Thanks a lot for the response! I checked /<path>/<to>/crawl/crawl-ref/source/saves/ and can confirm that it exists, but there is no des folder within it.
You speculated that maybe the saves directory wasn’t writable, and yes that appears to be the case ls -l | grep "saves" gave drwxr-xr-x 5 root root 4096 Apr 14 14:41 saves. I tried giving saves full write permissions (it produces drwxrwxrwx now) but running ./crawl still produces the same error.
If it’s helpful, here are results from a cntrl+p from the menu screen:
Initialization log:
Data directory ‘/home/crawl/crawl-ref/source/dat/’ found.
Loading databases… Loading spells and features… Loading maps…
Hello, welcome to Dungeon Crawl Stone Soup 0.32-a0-931-g5a2cda0630!
(c) Copyright 1997-2002 Linley Henzell, 2002-2023 Crawl DevTeam
Options read from “…/settings/init.txt”.
And here are results from ?V:
This is Dungeon Crawl Stone Soup 0.32-a0-931-g5a2cda0630 (Console)
Ah the info I was trying to find apparently only is visible with a debug build. I realize rebuilding is probably a pain, but if you could show the ?V output from some sort of make debug build, that should directly show what it thinks the save path is.
First, maybe try running from the command line:
./crawl -reset-cache -builddb
I’m not entirely sure why it isn’t producing an error in general, but if there’s an error message about this at all it should show up with that command.
Also, are you doing this as root? Even in a chroot I would recommend creating a regular user and doing this under that identity. (If you’re doing it as a non-root user with a root-owned directory, that will also compound permissions issues.)
Sure! I tried ./crawl -reset-cache -builddb and I get the same error as before:
Lua execfile error (dlua/sanity.lua): /home/crawl/crawl-ref/source/dat/dlua/sanity.lua:4: No map found for Zot:$
Regarding root: yes, within the chroot I’ve done everything as root (I’m new to cross-compiling, and so I just stuck with the default that the system gave me when I run sudo chroot /<path>/<to>/<environment>/).
Rebuilding isn’t bad. Do you think I should create a normal user account and try rebuilding like last time? Or should I stick with root and make the debug build?
Update: With the root user I tried making a debug build without success. The INSTALL.md file hints that it’s something like make debug -j4, make -j4 debug, or make debug but they all gave “make: *** No rule to make target ‘debug’. Stop.” on my system. How do I make a debug build?
Both the crawl_dir and save_dir values look dubious to me.
I think that those are what is expected for compiling in-repo on linux; the des cache is supposed to be in saves/des.
I’m afraid I’m sort of running out of ideas here, I’ll ping the dev channel though. When you say that you’re cross-compiling, do you mean that you’re building armhf on a non-arm device? (I think I had originally assumed you were building directly on the kindle.)
That’s right. I’m building for ARM within an armhf chroot (Debian 11.9) on an x86 machine (Ubuntu 22.04). I’m also testing the build directly within the chroot which built it (I’m not transferring to Kindle). Only after seeing success running the executable on the build machine would I try transferring it to Kindle.
I’ll add that these Kindles only have ~500-800 MHz processors, ~256 MB RAM, & 2-8 GB total storage space. So building directly on them is probably not practical.
One thought from the dev chat is that this could somehow be an endianness issue that is related to the mixed build environment (i.e. armhf and x86 do have different endianness). dcss is known to work in a pure arm environment (mac) so it may actually be worth trying transferring the build to a kindle and then testing it?
Beyond this it might be worth seeing if there’s a way to get in touch with the person on reddit who succeeded at getting this to work…
Regarding the person on Reddit: he’s me! The example on Kinlde that I posted to Reddit wasn’t running natively on Kindle. I was SSH’ed into crawl.akrasiac.org and playing there. There were terminal size/color problems to solve there to get a playable DCSS experience. With those solved I’m moving on to running it natively on the device itself
Well… ./crawl does not work on the Kindle - but I think it’s not crawl’s fault. I get a mysterious “file not found error” when I try to run the executable, even though the executable is definitely there.
After some online searching I found this, which seems like my issue.
This situation often arises when you try to run a binary for the right system (or family of systems) and superarchitecture but the wrong subarchitecture. Here you have ELF binaries on a system that expects ELF binaries, so the kernel loads them just fine. They are ARM binaries running on an ARM processor, so the instructions make sense and get the program to the point where it can look for its loader. But it’s the wrong loader.
I’m afraid this is beyond my skill to heal… Maybe I’ll just have to SSH into akrasiac to play from the Kindle.
Is it possible the build target should be armel and not armhf? May depend on exact processor. Regardless, after some more googling this does look extremely hard. If you return to this, the mobileread forum sounds like a place that might have people who could actually help, e.g. this thread though a bit old looks useful.
. I set up a Debian 11.9 armhf chroot environment and I followed the build instructions here. Everything seemed to build OK (some info-level outputs but no errors) but when I run the game with 