Linux AMD64 Build fails on Gentoo Linux. about openbor HOT 20 OPEN

Try building with gcc 7 or below.

from openbor.

Gentoo Linux doesn't have gcc 7. I have gcc 12.

https://packages.gentoo.org/packages/sys-devel/gcc

from openbor.

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 ?

from openbor.

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.

from openbor.

It seems the executable uses wayland. But, I don't know how to run it on wayland instead of xwayland.

from openbor.

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.

from openbor.

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.

from openbor.

I hated using wine.

from openbor.

I think appimage is not necessary for openbor. It just needs to produce a statically linked binary.

from openbor.

"statically linked binary" what does that mean?

from openbor.

$ 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.

from openbor.

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.

from openbor.

$ 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_flags

Appimage is already incompatible with mesa when SDL_VIDEODRIVER=wayland instead of SDL_VIDEODRIVER=x11.

from openbor.

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.

from openbor.

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.

from openbor.

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.

from openbor.

We found a fix for compiling on linux i will get back to you with a update soon

from openbor.

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

from openbor.

When did openbor start supporting cmake? 2 weeks ago? I'm still waiting for GCC 13 support because my system has gcc 13.

from openbor.

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.

from openbor.