Closed coreybruce closed 7 months ago
Hi
/mnt/Storage/projects/planetblupi-dev/Release/cmd.sh: line 20: ./configure: No such file or directory
make[2]: *** [CMakeFiles/zlib_Project.dir/build.make:92: src/zlib_Project-stamp/zlib_Project-configure] Error 127
make[1]: *** [CMakeFiles/Makefile2:116: CMakeFiles/zlib_Project.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Maybe the download of zlib has failed. Check the archive in the externals/
directory in order to be sure that it's really a tar.gz
and not an HTML page with an error like 404 for example.
You can try to delete externals/zlib-1.2.11.tar.gz
and make again
Note that on this page https://github.com/blupi-games/planetblupi-dev/releases/tag/v1.14.2, this archive
is a full dist with all externals tarball (at least for the versions used by planetblupi 1.14.2; maybe it's not exactly the same that the current master)
Hey sorry for not getting back to you and leaving it so late, I git cloned the latest dev version with the instructions and compiled it but I ran into this error with the make file
[ 48%] Completed 'libcurl_Project'
[ 48%] Built target libcurl_Project
make: *** [Makefile:111: all] Error 2
Looks like it's having an issue with makefile2
$(MAKE) $(MAKESILENT) -f CMakeFiles/Makefile2 all
This time I download Manjaro Linux x64 in order to try myself.
This time I download Manjaro Linux x64 in order to try myself.
Alright let me know how that goes :smile:
I can build mostly without problem when I upgrade FFmpeg to v6.1.1. But in this case it fails on runtime (even on Debian). Even FFmpeg v5 is a problem. Only with v4 it works fine but not on Manjaro.
I'm still investing
https://github.com/blupi-games/planetblupi-dev/assets/397862/d7c6d684-1398-4ce0-b32b-d99f54b0a2e3
This time it works.
cd planetblupi-dev
git checkout master
git pull
git submodule update --init --recursive
mkdir Debug
cd Debug
cmake -DCMAKE_BUILD_TYPE=Debug ..
make -j
Peek.25-03-2024.23-06.mp4
This time it works.
cd planetblupi-dev git checkout master git pull git submodule update --init --recursive mkdir Debug cd Debug cmake -DCMAKE_BUILD_TYPE=Debug .. make -j
Looks like it's almost fully functional other then it crashing
Do you have more details ? Stack trace for example.
Do you have more details ? Stack trace for example.
I was just replying to you getting it almost fully working, it seems like using the debug compile option got you a little further tho it still needs some fixes to stop the crashing
You can try. For me it's fine now when building with Manjaro x64.
Yeh I can confirm this also works without any issues both with compiling and test from my quick testing, I will have to test this on the Raspberry pi 4 next.
Hang on even tho it works on the dev version should we makes sure the the stable version works or does it not matter between the debug and stable? does the debug version have or do exra debugging stuff that isn't needed or a overhead @Skywalker13 ?
I will prepare a new release in some days (or weeks). There are only minor changes between the dev version and the last release 1.15.0. Before, note that I must check the build (with the changes about FFmpeg) on macOS and Windows.
If you want to build a version that looks like the stable release, just do that:
mkdir Release
cd Release
cmake -DCMAKE_BUILD_TYPE=Release ..
Seems like release works also, I assume you did something to fix it :D
Hey @Skywalker13 I've done you a favour, I have created and will maintain a Arch Linux AUR package for you compiled and hosted the binaries for Linux x64 and Amr64 for the package. If you have any updates or need me to compile or test new binaries please let me know as I am happy to help support this project :smiley:
all links to the package and git repos are down below https://gitlab.com/planetblupi https://aur.archlinux.org/packages/planetblupi-bin
By the way I had to create a launch script to to the weird behavior of the game file layout that the binary looks for
For some reason the file layout has to be exactly like this otherwise it will say the game files are not set correctly and doesn't like the files or the binary to be anywhere else on the system but in that specific layout
Lets use the example that all the files are inside a folder called planetblupi and assume ~ is planetblupi ~/bin/planetblupi ~/share/icons ~/share/planetblupi/data ~/share/planetblupi/fonts ~/share/planetblupi/image ~/share/planetblupi/movie ~/share/planetblupi/music ~/share/planetblupi/sound
So what I did when I packaged it was it all exactly as it was in /usr/share/games/PlanetBlupi and created a launch script that would cd to /usr/share/games/PlanetBlupi , cd to ./bin and then run the planetblupi
I also noticed there wasn't a desktop shortcut so I also made one that is provided on my git repo
In case of packaging for distribution, you should use the official dependencies for SDL2, FFmpeg, etc (provided by Arch Linux). When using planetblupi-dev it's for a standalone build (with all deps statically linked) and I use that for the AppImage (or DMG macOS and NSIS Windows).
But for distribution, the right way is to build only the planetblupi repository (and you must install all other dev dependencies as usual).
https://github.com/blupi-games/planetblupi
You can look for Debian (for and example): https://salsa.debian.org/games-team/planetblupi
I also noticed there wasn't a desktop shortcut so I also made one that is provided on my git repo
There is the desktop file:
But here you must build the "normal" way without the planetblupi-dev repository. And make install
deploys the desktop where appropriate.
But sorry, I don't have documentation for a build more "standard". And you must package SDL_kitchensink for Arch Linux before.
Hey @Skywalker13 I've done you a favour, I have created and will maintain a Arch Linux AUR package for you compiled and hosted the binaries for Linux x64 and Amr64 for the package. If you have any updates or need me to compile or test new binaries please let me know as I am happy to help support this project 😃
Thank you very much!
In case of packaging for distribution, you should use the official dependencies for SDL2, FFmpeg, etc (provided by Arch Linux). When using planetblupi-dev it's for a standalone build (with all deps statically linked) and I use that for the AppImage (or DMG macOS and NSIS Windows).
But for distribution, the right way is to build only the planetblupi repository (and you must install all other dev dependencies as usual). https://github.com/blupi-games/planetblupi
You can look for Debian (for and example): https://salsa.debian.org/games-team/planetblupi
Yep if you look at the pkgbbuild file I have all the dependencies sorted :smiley:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=planetblupi-bin
Yes I've seen. But when you build from the planetblupi-dev repository, then it's statically linked. planetblupi-dev is used to download and build in static all dependencies. Even if you specify the deps for the Arch package, these deps are not used.
To build with the official Arch dependencies you must use the planetblupi (without -dev) repository instead.
In your PKGBUILD file I see just that you provide binaries built via planetblupi-dev.
https://gitlab.com/planetblupi/binaries/1.15.0/-/raw/main/planetblupi-linux-x64.tar.xz
If I look with ldd:
14:30:53 ~/devel $ ldd planetblupi/bin/planetblupi
planetblupi/bin/planetblupi: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by planetblupi/bin/planetblupi)
planetblupi/bin/planetblupi: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by planetblupi/bin/planetblupi)
linux-vdso.so.1 (0x00007ffcc49ad000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f925f521000)
libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f9260424000)
libjxl.so.0.10 => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f925f340000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9260466000)
We can see that only libc-like libraries are dynamic. Because (like I said before), with planetblupi-dev all deps (excepted libc stuff) are linked statically in the planetblupi binary. And it's the wrong way in the case of distribution packaging.
Yes I've seen. But when you build from the planetblupi-dev repository, then it's statically linked. planetblupi-dev is used to download and build in static all dependencies. Even if you specify the deps for the Arch package, these deps are not used.
To build with the official Arch dependencies you must use the planetblupi (without -dev) repository instead.
In your PKGBUILD file I see just that you provide binaries built via planetblupi-dev.
https://gitlab.com/planetblupi/binaries/1.15.0/-/raw/main/planetblupi-linux-x64.tar.xz
If I look with ldd:
14:30:53 ~/devel $ ldd planetblupi/bin/planetblupi planetblupi/bin/planetblupi: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by planetblupi/bin/planetblupi) planetblupi/bin/planetblupi: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by planetblupi/bin/planetblupi) linux-vdso.so.1 (0x00007ffcc49ad000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f925f521000) libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f9260424000) libjxl.so.0.10 => not found libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f925f340000) /lib64/ld-linux-x86-64.so.2 (0x00007f9260466000)
We can see that only libc-like libraries are dynamic. Because (like I said before), with planetblupi-dev all deps (excepted libc stuff) are linked statically in the planetblupi binary. And it's the wrong way in the case of distribution packaging.
Yeah right so I will have to look into that, I also assume I will need to build and create a package for SDL_kitchensink also
Hey again I got the latest clone of this projects following the instructions but ran into a build issue to do with line 111 on the makefile
make: *** [Makefile:111: all] Error 2
here is the full log via gist https://gist.github.com/coreybruce/e7bcf9329a51ae2fb48d229ddbb70adc