Current State Of Linux Builds #1
Comments
|
One thing I notice, being on Gentoo running OpenRC, is that the binary, and compilation seem to hard require systemd. Not sure if there's a CMAKE flag included to disable systemd support or not. To be clear, not saying you need to support openrc at all, but maybe a compile flag to disable the systemd stuff would be nice. (I'm not very experienced with CMAKE so maybe there is a way I'm just not aware of). |
|
It is unusual that the project requires the entire Vulkan SDK, as opposed to just the headers. Any comment on this? |
|
For Flatpak, would you mind if I tried to make a package? I can't guarantee anything, but I could see if I can get something working later today |
|
Also-- Is there a reason vcpkg is used on linux? vcpkg is, no matter what microsoft says, designed for windows, and it doesn't make a ton of sense to have to compile all of the dependencies when they are already available in the various package managers. |
Sure, although we'd like to have an official flatpak package. I'm not sure if/how other emulators do that with their continuous builds, but maybe worrying about that is a later step and you should see if it requires some source code changes first. |
I ran into compilation issues on Windows when trying to compile with headers only after we switched from VS solution to cmake. I forgot where exactly the dependency comes from but it was meant as a quick and dirty fix to just add the whole thing. In general there are a lot of dependencies that could probably be optimized out.
I like it because it generally seems to be the most hassle free across platforms. But yes, ideally we would conditionally use system libraries if present. Will look into this |
|
I sadly couldn't get this to compile on Arch so I'm sharing my steps in case somebody else wants to give it a whirl:
Temporary solution: Turn lines 250 and 251 into comments in
Workaround: Change line 10 into
Workaround: Remove the curly brackets in line 134 and 144 in
|
Even if I haven't been involved in Cemu before, if you approve of it, wouldn't that make it official? Also, when it's ready for publishing I could ask to have you added as collaborators on the repo, so you could make changes as well
Flatpaks are almost always compiled from source on Flathub's servers if the code is available. The only exception I can think of is osu, where it's because a small bit of code that's required for online functionality is proprietary to avoid cheaters.
A .desktop file (for app menus) and a metadata file (for app stores) will be required. These can also be added in the flatpak instead of upstream, but upstreaming is preferred since these aren't Flatpak-specific and are also useful for other distribution methods. You can find info about these at these links: |
@Anuskuss looks like you're missing these headers. On Ubuntu, you can get them from this package: glslang-dev. I am unsure about Arch, but I would make sure the -devel packages are getting installed if they exist, so you have the required development packages, not the release packages. Commenting include lines is probably not going to net any positive results. I would focus on fixing missing dependencies or why functions are missing. Most likely the required development files are not installed. (I'm not sure if this package was overlooked on the dependencies, but Exzap did say the linux build needs work. FYI it looks like pacman has an apt-file search alternative, pacman -F. This allows searching for packages that provide a specific file, including searching the relative path, like SPIRV/Logger.h. |
|
@Drakonas I appreciate you trying to help but I'm not really looking for support. I'll just wait for the AUR/AppImage/Flatpak.
Oh no, they are there. Don't know why CMake can't find them though. |
|
I think most people have figured this out already but the precompiled binary is way easier to get going. Just need to install Unfortunately audio doesn't seem to work and it can't read WUD/WUX but it's a start. Will investigate more tomorrow. Although I did try manually installing the packages (from Debian) and that still didn't work... |
|
I can't running any game here on ubuntu 22.04, when i try to add the mlc01 or a game folder it crash, i workaround this crash editing settings.xml but when i try to run a game i get another crash. Crash when adding folders
Crash when i start a game with vulkan backend ./Cemu
Crash when i start a game with opengl backend ./Cemu
|
|
i hope we see AUR support soon |
|
@Anuskuss I'm going through almost identical steps as you and getting the same issues more or less. I am, however, trying to avoid modifying source. One thing I'm curious about, are you sure |
|
I attempting to compile on Arch Linux as well, although still on clang 14, and I saw these same issues. For others looking to try, it should be noted that I also needed the |
|
@aquova The alternative to that (which would also be more cross-platform if to be added to documentation) is just downloading the headers: sudo mkdir -p /opt/vulkansdk
curl -JLO https://sdk.lunarg.com/sdk/download/1.3.224.0/linux/vulkansdk-linux-x86_64-1.3.224.0.tar.gz
sudo tar -C /opt/vulkansdk/ -xf vulkansdk-linux-x86_64-1.3.224.0.tar.gz
rm vulkansdk-linux-x86_64-1.3.224.0.tar.gzThen you can set However, it is definitely easier to use pacman on Arch. |
|
Tried to compile it here on ubuntu 22.04, but i'm getting a error on the final of the build |
It's not unheard of; blender-git ships siloed library trees (although via optional script, not a hard dependency) as they aren't shy about deploying fixes ahead of upstream. For code with frequent releases it's also helps avoid the packaging delay. Vulkan-headers are a month behind on Gentoo, for example. |
saying it is allowed does not mean they want to provide support thus it is not official, just put community build or unofficial build in the name on flathub. You can also always submit your work back to the official project so they can choose weather to use some of your work in the official build or not. |
|
Fedora is stuck here `CMake Warning at buildtrees/versioning_/versions/openssl/557ff31f9a64f01cd0d98dd44793ce3c7fd32893/portfile.cmake:7 (message): It can be installed on alpine systems via apk add linux-headers. -- Using cached openssl-openssl-openssl-3.0.5.tar.gz. Call Stack (most recent call first): error: building openssl:x64-linux failed with: BUILD_FAILED You can also use the prefilled template from /home/matt/Cemu/build/vcpkg_installed/vcpkg/issue_body.md. -- Running vcpkg install - failed |
|
Having the same issue on Fedora aswell. |
|
What's the output of |
|
So, I am writing a PKGBUILD for the Arch Linux AUR, and I am currently getting errors linking to wxwidgets and imgui. So I looked and say Arch Linux installs its headers for the package So, is this an issue with how Arch packages its headers for Also, it looks y'all didn't set your C++ and C standard cause I had to manually set them as I had problems with some things being missing from the Here is my cmake command btw And, here are the build dependencies and make dependencies |
I am not a member of the cemu team, however I imagine reporting issues with other peoples packages is not helpful. I would comment on the aur package |
I got it fixed by installing the openssl build dependencies. |
|
HurricanePootis is having errors with creating an AUR package, not with someone else's package |
ah ok got it lol. |
Any reason you are using |
It looks like the filepath for |
Honestly, I just use make to have one less dependency (as it shouldn't change anything with CMake), but I will try with ninja to see if it changes everything |
|
Could somebody check if #1 is working for them? I'm encountering linking issues related to some missing wxWidgets symbols. Compilation requires wxWidgets 3.2, which is not available on Debian-based distros. Here are the commands to download and build that work in progress branch; you'll have to install all the required dependencies yourself. Please do not report issues here, but report them on #75. |
|
@Tachi107 Newest wxWidgets version is available for Debian-based with this repo: https://docs.codelite.org/wxWidgets/repo320/#ubuntu-and-debian |
Please don't install deb packages from random places. The official Debian package for wxWidgets 3.2 has already been completed, but it has not been uploaded to Debian because the review process is long. If you want to install the official wxWidgets 3.2 package on Debian, you have to build it yourself (for the time being). But please don't do this if you have no idea what you are doing. And remember to remove the packages you have built yourself after finishing using them. |
|
Excited to see that the last secret has been cracked. Time to clean up the PKGBUILD. Changes:
Future:
Right now, it's pulling from tomlally/Cemu, but once #80 is merged, I think it's ready for prime time and we¹ can submit it to the AUR. This of course wouldn't have been possible without the help of the community, particulary @zjeffer (debug mode), @Rubo3 (license/format-security), @robertkirkman (python dep), @bscubed (submodules), @abouvier (linker error) and @tomlally (gcc). ¹ If nobody steps forward as a potential maintainer, I'll do it but I'd rather not because I have no experience in that regard. |
ghost
mentioned this issue
|
@Anuskuss there is already |
|
|
|
|
|
@Somaxa8 Try building with gcc instead, to do that replace |
|
@bbaster it worked, thanks! |
I didn't know that. I thought this was a team effort but congrats to @abouvier for being the first I guess. Me personally, I wouldn't feel comfortable publishing some half-assed mess to the AUR but that's just me.
Well my plan was to also get rid of
I removed
I don't really see a point in that. I don't even know if I should continue my PKGBUILD now that abouvier beat me to it. They certainely have good ideas (getting rid of Regardless, I'd still like to run some benchmarks to see which compiler and flag combination is the best (it currently runs worse than wine AFAIK). No point really fixing the vcpkg situation and getting rid of the patch(es) because I'm not interested in publishing this as |
|
Il giorno dom 28 ago 2022 alle 13:56:01 -07:00:00, Anuskuss
***@***.***> ha scritto:
I don't even know if I should continue my PKGBUILD now that abouvier
beat me to it. They certainely have good ideas (getting rid of vcpkg,
mounting the cemu directory instead of putting it in ~/.local/share)
but I find it sketchy that they didn't communicate with the rest of
us at all, kept their improvements for themselves (instead of PRing
or helping out in #75) and that they uploaded it to the AUR in this
state. My PKGBUILD looks and functions much better and I still
wouldn't want to publish it until it's perfect.
Pros and cons of the chaotic nature of the AUR ;)
…--
OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
|
|
I maintain a couple popular AUR packages, would the devs mind if for now I made a |
Ah yes, a third one. Just kidding of course but we already have a public and a semi-public one. |
|
Ah, gotcha. |
This is a big rework of how dependencies are handled internally. All the calls to CMake functions changing directory-wide properties that were previously used to link to external and internal dependencies have been replaced with their "target_" counterparts. This makes it possible to express more clearly the relationships between different targets and should also make the build script more robust in general. In doing this, I've also made it possible to link to system libraries if so desired; the versioned calls to find_package() will make sure that the found dependencies are compatible with the ones required by Cemu, and will abort the build otherwise. Cemu's internal targets are deeply interconnected, making it hard to fully benefit from a target-based approach. Nonetheless, I did my best to mark PUBLIC dependencies as such, for example when an internal target like CemuGui exposes a dependency as part of its API, i.e. it includes a third party header in one of its public headers. This will significantly help with improving the build experience on Linux, thus helping a bit with the resolution of cemu-project#1.
|
Here are my results from a quick (and unscientific) benchmark*:
* Values are in FPS and each line contains each arguments above it As expected the flags don't really do much (except For comparison, this is the Clang v12 build before and after release mode worked and the precompiled binary:
Meaning your self-compiled Clang (v14) build beats the pre-combiled "Ubuntu" build. But unfortunately it's all behind Windows currently:
Although seeing that v2.0 is worse than v1.26.2 gives me hope that we can get some of the performance back in the future. Last but not least (even though it's not related to Linux per se): If you're wondering if Vulkan beats OpenGL on NVIDIA GPUs:
Conclusion: Because Clang performs measurably better than GCC I decided to prefer it (use if Clang is installed but not the default compiler) in my PKGBUILD but because GCC works and Clang is only marginally faster, I decided against depending on it. I will however leave the ¹ First time running the Clang build Cemu crashed. It only happend once though and never again. ² Everything enabled ( ³ No audio. |
|
Try -ofast |
Unlikely to improve performance. Would probably just break stuff and lead to undesired issue reports. |
this is great except could you please state what hardware specs this was done with because that is of course the biggest factor of all that impacts performance, and people won't know whether they should be having more or less FPS compared to you when they try to copy one of your optimization configurations, unless they know whether their hardware is considered more or less powerful than yours EDIT: also what game is that because that's probably the only other thing you didn't say that could be argued to have an even bigger effect on the resulting FPS than the hardware |
|
Continued in #107 since the useful info got burried. |
and others
Linux builds of Cemu are not recommended yet for beginners, since currently it lacks a few things:
You can use this issue to share your experiences, issues or build tips!
The text was updated successfully, but these errors were encountered: