msmalik681
commented
1 year ago Try building with gcc 7 or below.
Open amano-kenji opened 1 year ago
msmalik681
commented
1 year ago Try building with gcc 7 or below.
amano-kenji
commented
1 year ago Gentoo Linux doesn't have gcc 7. I have gcc 12.
msmalik681
commented
1 year ago Newer builds work with newer gcc but if your trying to build the last stable then i suggest using a virtual machine with ubuntu 20.04. So does the linux appimage not work for you ?
amano-kenji
commented
1 year ago The appimage works for now without firejail. But, firejail often fails to deliver ALSA devices and input devices to appimage. Thus, I extracted files from appimage and run them in firejail.
How long is AppImage supposed to work? I suppose, not long because the executable still uses system shared libraries.
amano-kenji
commented
1 year ago It seems the executable uses wayland. But, I don't know how to run it on wayland instead of xwayland.
amano-kenji
commented
1 year ago I suggest replacing build.sh with meson or cmake or just plain configure.
I don't expect build.sh to be actually portable across various operating systems or across different machines.
msmalik681
commented
1 year ago I will make sure everything is working in future releases but for now I know this is a terrible work around but maybe use the windows executable with wine.
amano-kenji
commented
1 year ago I hated using wine.
amano-kenji
commented
1 year ago I think appimage is not necessary for openbor. It just needs to produce a statically linked binary.
msmalik681
commented
1 year ago "statically linked binary" what does that mean?
amano-kenji
commented
1 year ago $ ldd OpenBOR
linux-vdso.so.1 (0x00007ffcc9596000)
libSDL2-2.0.so.0 => ../lib/libSDL2-2.0.so.0 (0x00007fecaf000000)
libSDL2_gfx-1.0.so.0 => ../lib/libSDL2_gfx-1.0.so.0 (0x00007fecaec00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fecaf372000)
libvorbisfile.so.3 => ../lib/libvorbisfile.so.3 (0x00007fecae800000)
libvorbis.so.0 => ../lib/libvorbis.so.0 (0x00007fecae400000)
libvpx.so.3 => ../lib/libvpx.so.3 (0x00007fecade00000)
libpng12.so.0 => ../lib/libpng12.so.0 (0x00007fecada00000)
libm.so.6 => /lib64/libm.so.6 (0x00007fecaef22000)
libc.so.6 => /lib64/libc.so.6 (0x00007fecaea2a000)
libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007fecaee32000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fecaf36a000)
libpulse.so.0 => ../lib/libpulse.so.0 (0x00007fecad600000)
libsndio.so.6.1 => ../lib/libsndio.so.6.1 (0x00007fecad200000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fecae6ba000)
libXext.so.6 => ../lib/libXext.so.6 (0x00007fecace00000)
libXcursor.so.1 => ../lib/libXcursor.so.1 (0x00007fecaca00000)
libXinerama.so.1 => ../lib/libXinerama.so.1 (0x00007fecac600000)
libXi.so.6 => ../lib/libXi.so.6 (0x00007fecac200000)
libXrandr.so.2 => ../lib/libXrandr.so.2 (0x00007fecabe00000)
libXss.so.1 => ../lib/libXss.so.1 (0x00007fecaba00000)
libXxf86vm.so.1 => ../lib/libXxf86vm.so.1 (0x00007fecab600000)
libwayland-egl.so.1 => ../lib/libwayland-egl.so.1 (0x00007fecab200000)
libwayland-client.so.0 => ../lib/libwayland-client.so.0 (0x00007fecaae00000)
libwayland-cursor.so.0 => ../lib/libwayland-cursor.so.0 (0x00007fecaaa00000)
libxkbcommon.so.0 => ../lib/libxkbcommon.so.0 (0x00007fecaa600000)
librt.so.1 => /lib64/librt.so.1 (0x00007fecaf362000)
libogg.so.0 => ../lib/libogg.so.0 (0x00007fecaa200000)
libz.so.1 => /lib64/libz.so.1 (0x00007fecaf342000)
/lib64/ld-linux-x86-64.so.2 (0x00007fecaf39a000)
libpulsecommon-8.0.so => ../lib/libpulsecommon-8.0.so (0x00007feca9e00000)
libdbus-1.so.3 => ../lib/libdbus-1.so.3 (0x00007feca9a00000)
libbsd.so.0 => ../lib/libbsd.so.0 (0x00007feca9600000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fecae68a000)
libXrender.so.1 => ../lib/libXrender.so.1 (0x00007feca9200000)
libXfixes.so.3 => ../lib/libXfixes.so.3 (0x00007feca8e00000)
libffi.so.6 => ../lib/libffi.so.6 (0x00007feca8a00000)
libsystemd.so.0 => ../lib/libsystemd.so.0 (0x00007fecae372000)
libwrap.so.0 => ../lib/libwrap.so.0 (0x00007feca8600000)
libsndfile.so.1 => ../lib/libsndfile.so.1 (0x00007feca8200000)
libasyncns.so.0 => ../lib/libasyncns.so.0 (0x00007feca7e00000)
libapparmor.so.1 => ../lib/libapparmor.so.1 (0x00007feca7a00000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fecaf33a000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fecaf332000)
libselinux.so.1 => ../lib/libselinux.so.1 (0x00007feca7600000)
liblzma.so.5 => ../lib/liblzma.so.5 (0x00007feca7200000)
libgcrypt.so.20 => ../lib/libgcrypt.so.20 (0x00007feca6e00000)
libnsl.so.1 => ../lib/libnsl.so.1 (0x00007feca6a00000)
libFLAC.so.8 => ../lib/libFLAC.so.8 (0x00007feca6600000)
libvorbisenc.so.2 => ../lib/libvorbisenc.so.2 (0x00007feca6200000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fecaf31a000)
libpcre.so.3 => ../lib/libpcre.so.3 (0x00007feca5e00000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007fecae662000)Those are libraries dynamically linked by OpenBOR linux executable. The dynamically linked libraries from appimage are in '../lib/' directory. Those can be linked statically instead.
A statically linked executable would have no dynamically linked library or only a few that will not change over decades.
amano-kenji
commented
1 year ago If I was responsible for the build, I would replace build.sh with meson. If meson is not an option, then cmake or something easier than cmake.
I would produce a statically linked binary instead of an appimage. A statically linked binary is simpler than an appimage.
An appimage may be beneficial when there are resource files that should come with the binary. If there is no resource file that should come with the binary, then a statically linked executable is simpler.
amano-kenji
commented
1 year ago $ SDL_VIDEODRIVER=wayland ./OpenBOR_3.0_6391.AppImage
./OpenBOR_3.0_6391.AppImage: symbol lookup error: /usr/lib64/libEGL_mesa.so.0: undefined symbol: wl_proxy_marshal_flagsAppimage is already incompatible with mesa when SDL_VIDEODRIVER=wayland instead of SDL_VIDEODRIVER=x11.
msmalik681
commented
1 year ago Wow i did not know there was such a downside to a appimage but the alternative is to build from source again something we are looking to fix for future builds.
There have been talks of moving to a more updated comiler but it would have to work across all platforms we support.
amano-kenji
commented
1 year ago The actual downside of appimage is that since it involves more moving parts than a statically linked executable, firejail is still buggy with appimage. Security containers like firejail and flatpak can be buggy with appimage until they figure out how to use appimage.
Fixing incompatibility with mesa requires static linking which can be done with or without appimage. Or, you can just update the codebase to make it compatible with latest versions of mesa.
amano-kenji
commented
1 year ago I figured out why the appimage didn't have access to devices in firejail. It's going to be fixed.
Appimage is fine, but I want to build it on gentoo linux and package it for gentoo linux.
msmalik681
commented
1 year ago We found a fix for compiling on linux i will get back to you with a update soon
SumolX
commented
2 months ago I see the original issue is an engine bug. But as of today we now support cmake. Let me know if you run into any issues. Instructions are here: https://github.com/DCurrent/openbor/blob/master/COMPILING.md
amano-kenji
commented
2 months ago When did openbor start supporting cmake? 2 weeks ago? I'm still waiting for GCC 13 support because my system has gcc 13.
SumolX
commented
2 months ago About 3 weeks ago and 2 weeks ago on instructions. It's fairly new.... currently missing android support but all major OS are supported.
yeah what you identified is an engine bug... not so much a compiler issue. New compilers get better at reporting issues with code.
Description
I think build.sh is extremely fragile. I wish it was replaced by cmake or meson. If you want an easy experience, meson.
Debugging
Reproduce
./build.sh 4Expected behavior
No error.
Version