Multiple Errors when trying to compile on Linux

[Garrett96]

Overview

I tried multiple different methods to get the game running, and I failed to get anything to work. Deleting the zig-cache folder did not seem to help, and the exact same error messages still occured.

System Information

OS: Pop!_OS 22.04 LTS x86_64 Display Server: x11

Install Attempts

• Downloading & extracting the file
• Git clone

Attempts to Run Cubyz

• Manually clicking run_linux.sh inside the file manager. (This didn't do anything)
• Right-clicking run_linux.sh and selecting Run Program.
• Running ./run_linux.sh & sudo ./run_linux.sh in the terminal.
• Installing Zig and running zig build run.

Terminal Errors

I cropped out the lengthy file pathing and just ripped the raw error messages. Let me know if you want the full context. The output was the same both both installation methods.

Error message for running run_linux.sh and sudo run_linux.sh:

Detecting Zig compiler...
Zig compiler is valid.
Building Zig Cubyz (-Doptimize=ReleaseFast) from source. This may take a few minutes...
install
└─ install Cubyzig
└─ zig build-exe Cubyzig ReleaseFast native failure
error: error: unable to find dynamic system library 'asound' using strategy 'paths_first'.
...
error: unable to find dynamic system library 'x11' using strategy 'paths_first'.
...
error: unable to find dynamic system library 'GL' using strategy 'paths_first'.
...
Build Summary: 0/3 steps succeeded; 1 failed (disable with --summary none)
install transitive failure
└─ install Cubyzig transitive failure
└─ zig build-exe Cubyzig ReleaseFast native failure

Press enter key to continue. (Or export NO_PAUSE=1 to skip this prompt.)

> Error message for `zig build run` after Zig Installation:

... error: no field named 'path' in union 'Build.LazyPath' .root_source_file = .{.path = "src/main.zig"}, ^~~~ ... 2: note: union declared here pub const LazyPath = union(enum) { ^~~~~ ...

[archbirdplus]

First issue: not our fault. https://github.com/ziglang/zig/issues/8103

Second issue: not sure, it doesn't really make sense.

I'll work on these when I have the time. If you really want, add the library path to the build.zig like they did in the zig issue I linked above.

[archbirdplus]

git clone and ./run_linux.sh are sufficient and equivalent. You seem to be missing some -dev packages. There is a full list of linux packages under "Note for Linux Users" in the README:

sudo apt install libgl-dev libasound2-dev libx11-dev libxcursor-dev libxrandr-dev libxinerama-dev libxext-dev libxi-dev

Have you gotten it to work?

[archbirdplus]

Second issue: don't use your own zig installation, as it seems to be out of date. Cubyz installs a compiler in ./compiler/zig/zig, but it's better to just use run_linux.sh.

[Garrett96]

oh hey, look at that. I did install the dependencies... for the zip file extracton- which gave me the first error chunk too. It seems I forgot to install the dependencies again.

For any future PopOS users reading this, there's only one way to do it. tldr;

1. git clone https://github.com/pixelguys/Cubyz
2. install dependencies
3. ./run_linux.sh in the terminal

It works!

[archbirdplus]

Really? Could you try one of the other options again, now that you have all the dependencies? I remember specifically enabling all of them in #252 ...

[IntegratedQuantum]

I think the problem here is that, on linux, running a bash script doesn't open the terminal in all cases. For example on my computer I get to choose:

So the solution to keep the terminal open doesn't work, because there is no terminal open to begin with. Maybe we can find a way to always open a terminal?

[Garrett96]

Really? Could you try one of the other options again, now that you have all the dependencies? I remember specifically enabling all of them in #252 ...

@archbirdplus I did extract -> cd Desktop -> cd Cubyz-master -> install dependencies -> ./run_linux.sh again and it worked this time. When my first try failed it led me down the rabbit hole of trying all the other methods. Maybe a dependency install attempts failed and I didn't notice? Not sure why it burped.

Side note- thought this console log might be worth sharing.

...
Detecting Zig compiler...
Your Zig is the wrong version.
Deleting current Zig installation...
Downloading zig-linux-x86_64-0.13.0-dev.75+5c9eb4081...
--2024-05-22 14:18:56--  https://ziglang.org/builds/zig-linux-x86_64-0.13.0-dev.75+5c9eb4081.tar.xz
...

[archbirdplus]

Side note

That is intended behavior. It notices that it's missing its zig compiler, and installs the right one in Cubyz/compiler. But thanks for pointing it out, I should change the message to note that there is no zig compiler yet.

[Garrett96]

I think the problem here is that, on linux, running a bash script doesn't open the terminal in all cases. For example on my computer I get to choose:

So the solution to keep the terminal open doesn't work, because there is no terminal open to begin with. Maybe we can find a way to always open a terminal?

@IntegratedQuantum It seems there's a way for a shell script to check if a terminal is open, and then open one if not.

Something along these lines:

#!/bin/bash

# checks if running in a terminal
if [ ! -t 0 ]; then
  # if not running in a terminal, opens a new one
  gnome-terminal -- "$0" "$@"
  exit
fi

# Your actual shell script code goes here
echo "Running the main script..."
# ... rest of your script ...

[archbirdplus]

Interesting.

[IntegratedQuantum]

Ok, that might might work. What about systems without a gnome terminal though?

[archbirdplus]

Let's close this issue and open split it into one for rewording the README and one for opening a terminal.

[IntegratedQuantum]

How would you reword the readme?

[archbirdplus]

I mean, I always think "the README is so chaotic". All the important parts are just so scattered and disorganized, and it seems that people are constantly confused about it. It could definitely benefit from a proper rewrite. I have some radical changes in mind but I don't trust myself to do them.

I just checked though, the -dev notes are literally in the next paragraph. I don't know how much you can compensate for people's attention span.

Another issue: As it stands now, the errors are non-trivial. It took me (a contributor) an hour of reading bug reports and thinking before realizing it was actually covered in the README. My pet peeve is when the build process is partially specified in one place, then fails without an indication of why, and I find that the answer was in a completely different place (i.e. help forums). If we could catch the error, we could emit our own suggestions/fixes. If they're good enough, the user wouldn't need to maintain any broad understanding of the build system and yet could resolve issues on their own. And then, we could simplify the README, make it more relevant, and more likely to be read in the first place.

[Garrett96]

What about systems without a gnome terminal though?

@IntegratedQuantum not entirely sure, i read #385 and it seems a bit hectic.

don't know how much you can compensate for people's attention span.

@archbirdplus i did actually install the dependencies the first time, but when that failed i rm -r'd that repo and forgot to re-install them again lol. So that was my fault. I just tested making it all one line and it works.

like this:

git clone https://github.com/pixelguys/Cubyz && sudo apt install libgl-dev libasound2-dev libx11-dev libxcursor-dev libxrandr-dev libxinerama-dev libxext-dev libxi-dev -y

[archbirdplus]

rm -r Cubyz removes your Cubyz download, and does not uninstall packages from your global apt installation directory.

[Garrett96]

oh yeah, you're right. For context, I went through my command history just now, I definitely did two installs of the dependencies, and it worked the second time with the git clone (the git clone failed before running the dependency install again). not sure why that happened.

edit: Did as much digging as I could, and the best potential explanation I could find is that something happened with the initial extract.

[archbirdplus]

I doubt that git or zip compression were at fault. At the very least, it would have caused very different errors.

Did you use the same sudo apt line both times? Did you accidentally enter n or ^C? Did you see any other odd messages there? When you reinstalled the packages, did all of them note "already present" or the like?

[Garrett96]

exact same command both times. I read it could potentially have been a metadata difference between the two install's, but I doubt that's what happened. Technology burps sometimes. I'm not even sure if i can re-create what happened.