nesbox/TIC-80

tic80 behaves differently when run from source checkout

Opened this issue · 3 comments

technomancy commented

I've built the pro version of TIC80 in my ~/src/tic80/build directory. Then I've copied the tic80 executable from build/bin/tic80 into ~/bin/tic80. When I do this, it can no longer load text carts any more:

$ sha1sum ~/bin/tic80
e46d19a6141b5a702ad77667a6b750ad726e13fa  /home/phil/bin/tic80
$ sha1sum ../tic80/build/bin/tic80 # they're the same contents
e46d19a6141b5a702ad77667a6b750ad726e13fa  ../tic80/build/bin/tic80
$ ~/bin/tic80 --cli --cmd "load tower.fnl"

file not found$ # oops; error message is missing newline
$ ../tic80/build/bin/tic80 --cli --cmd "load tower.fnl"

cart tower.fnl loaded!
use RUN command to run it

However, the copy in my ~/bin directory seems to have no trouble loading .tic carts. It seems that maybe moving it out of the source tree causes it to forget that it's a pro build?

The latest stable tag (v1.1.2837) does not appear to be affected by this problem, but git main does.

nesbox commented

We added an option to build languages as shared libs, maybe you need to also copy fennel.so to ~/bin/tic80.
Or build everything statically using -DBUILD_STATIC_DEFAULT=ON.

technomancy commented

I tried it with the -DBUILD_STATIC_DEFAULT=ON cmake flag and it still exhibited the broken behavior; it still says "file not found" when the tic80 executable is copied out of the build directory.

For my own purposes, I was able to solve this problem by using a symlink as ~/bin/tic80 instead of copying the executable, so I am not stuck any more. However, the same underlying problem is likely to confuse other users who are accustomed to building from source.

To my understanding, it seems like using shared libraries is a really great feature for distro packagers; they don't like to package programs with static libraries included. So this seems like a great feature for getting TIC80 integrated into distros, and I'm glad to see it.

But I question whether it's a good idea to enable shared libraries by default, since it does make things more complicated. I expect most people building from source who aren't distro packagers might not want shared libraries because they cause problems like this. Should it be an opt-in flag instead?

But maybe I'm misunderstanding it and shared libraries have benefits for the average person building from source that I'm unaware of.

runemoennike commented

I have a similar issue when compiling from source on a Raspberry Pi 400 running the 64-bit "Bookworm" version of the RPi OS. I followed the instructions from the readme. After compiling, I can run using "tic80" from any folder, but I cannot save, load or create new carts without getting an file not found error. For "new" the error is Not found any languages. If I run from ./build/bin directly, it works fine.

Setting -DBUILD_STATIC_DEFAULT=ON doesn't seem to make a difference, but after searching around the repo, I tried -DBUILD_STATIC=ON instead which resolves the issue.

Should I add this to the readme, or do you prefer to fix the installation step? Unfortunately I'm not well versed enough in either cmake or linux to help there.

  • 👍1
  • 🎉1