blupi-games / planetblupi-dev

Planet Blupi development bundle (main repository)
https://www.blupi.org
GNU General Public License v3.0
51 stars 9 forks source link

Build issues on Manjaro x64 #12

Closed coreybruce closed 7 months ago

coreybruce commented 2 years ago

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

Skywalker13 commented 2 years 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

Skywalker13 commented 2 years ago

Note that on this page https://github.com/blupi-games/planetblupi-dev/releases/tag/v1.14.2, this archive image

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)

coreybruce commented 7 months ago

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
Skywalker13 commented 7 months ago

This time I download Manjaro Linux x64 in order to try myself.

coreybruce commented 7 months ago

This time I download Manjaro Linux x64 in order to try myself.

Alright let me know how that goes :smile:

Skywalker13 commented 7 months ago

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

Skywalker13 commented 7 months ago

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
coreybruce commented 7 months ago

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

Skywalker13 commented 7 months ago

Do you have more details ? Stack trace for example.

coreybruce commented 7 months ago

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

Skywalker13 commented 7 months ago

You can try. For me it's fine now when building with Manjaro x64.

coreybruce commented 7 months ago

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.

coreybruce commented 7 months ago

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 ?

Skywalker13 commented 7 months ago

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 ..
coreybruce commented 7 months ago

Seems like release works also, I assume you did something to fix it :D

coreybruce commented 7 months ago

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

coreybruce commented 7 months ago

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

Skywalker13 commented 7 months ago

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

Skywalker13 commented 7 months ago

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: image

image

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.

Skywalker13 commented 7 months ago

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!

coreybruce commented 7 months ago

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

Skywalker13 commented 7 months ago

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.

coreybruce commented 7 months ago

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