-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux AMD64 Build fails on Gentoo Linux. #277
Comments
Try building with gcc 7 or below. |
Gentoo Linux doesn't have gcc 7. I have gcc 12. |
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 ? |
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. |
It seems the executable uses wayland. But, I don't know how to run it on wayland instead of xwayland. |
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. |
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. |
I hated using wine. |
I think appimage is not necessary for openbor. It just needs to produce a statically linked binary. |
"statically linked binary" what does that mean? |
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. |
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. |
Appimage is already incompatible with mesa when SDL_VIDEODRIVER=wayland instead of SDL_VIDEODRIVER=x11. |
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. |
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. |
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. |
We found a fix for compiling on linux i will get back to you with a update soon |
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 |
When did openbor start supporting cmake? 2 weeks ago? I'm still waiting for GCC 13 support because my system has gcc 13. |
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 4
Expected behavior
No error.
Version
The text was updated successfully, but these errors were encountered: