-
Notifications
You must be signed in to change notification settings - Fork 173
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
Add aarch64 support to raknet and CMakesLists #111
Conversation
Even if this compiles, do you have a MySQL connector library for ARM? |
I wrote in the readme. The ubuntu repositories have the library libmysqlcppconn-dev compiled for aarch64 |
Have you ensured that this doesn't break anything on x86? Also is there any chance you could fetch the binaries like on x86 with a FetchContent call from anywhere, or is that not going to be possible? |
I have also been looking into this and have what looks like a working build although not much testing done yet and still in progress, especially with the CmakeLists.txt (https://github.com/jumpy-badger/DarkflameServer/tree/AArch64-port). From what I've been looking at the raknet defines in this look off, aarch64 and ps3 aren't compatible defines. Aarch64 has 8 float registers instead of 12 and is also not powerpc. I've used the mariadb cpp connector in place of the mysql one and built it from source. It's required a few minimal code changes and seems to be working. I should probably mention as well that the CMAKE_SYSTEM_PROCESSOR variable is not guaranteed to correspond to the target architecture. |
I can confirm that x86 still compiles with my patches and works fine. Regarding fetching the binaries I couldn't find them not as packages for distros. I do have the links for deb and rpm. Regarding the raknet you're correct but it doesn't seem to matter since I arrived at gnarled forest and the server looked to run completely fine. I didn't really have time to look into what is actually happening so I just added the aarch64 flag without actually looking at the config so that I see if it even compiles, Turns out it even works perfectly 🤷♂️. |
Would probably be good to add a section to the README about ARM builds. |
It's added in my patches. |
Is pulling the ubuntu package going to work for other distros (e.g. arch)? Building from source seems better (I think?). I couldn't get the mysql connector to compile from source which is why I switched to the mariadb one. Are the DLU team okay with switching to the mariadbconnector for linux builds? |
I do think building from source seems better in this case. I'm fine with dropping my pull request to make way for @jumpy-badger's which looks to be identical apart for the mariadbconnector part. |
Personal opinion though is that mysql connector should be switched completely to mariadb connector across the codebase, since it's not a good idea to mantain two different versions when mariadb can just replace it for all platforms. |
I agree with that, thought it might be better to limit how much this affected other builds to start with and address a full switch in a separate issue. |
Honestly it is probably a better solution to drop standard MySQL support entirely and opt for MariaDB… @DarwinAnim8or @Wincent01 @MickVermeulen thoughts? |
Seems like there’s no macOS binaries. I am in favor of it tho, I think supporting DLU on x86 and ARM is more important than which platform it specifically runs on. If we were to take that step I’d be in favor of dropping native Windows and macOS support in favor of using WSL and multipass for Ubuntu VMs. Will not only streamline the setup but will also make sure we can actually run on all platforms, native or not. |
If we compile from source we shouldn't have to drop support for any platform though? |
Fair enough, how are the build times for that? |
I think that it would be smart to instead fetch the binaries for platforms that have them prebuilt and build the source only if a binary isn't available. Considering that 98% of the systems running this will be x86 windows and linux I think we should prefetch those binaries specifically(conditionally of course). |
I agree that building from source would be a good thing for macOS anyway, it would get rid of all the obscure symlinking build steps. |
I'll update my branch so that every build uses the new connector and make a pull request then. The mariadb connector looks like it should work with mysql databases but I'll check when I test a Windows build. I don't have a Mac so someone verifying if it works on Mac once I've made the changes and submitting any fixes for it would be appreciated. Fetching binaries for Windows should be fine but there aren't any generic ones to fetch for Linux so will have to build from source. If we're gonna build from source on Linux and Mac should we just do the same for Windows? |
I can verify on a Mac, let me know if you've updated the cmakefile to reflect building the mariadbconnector. Ideally I'd first just have a version that builds and links from source that actually works with MariaDB. Maybe our cmake wizard @averysumner can elaborate a bit more on that. |
I can approve this script compiles on a RPI 4 8GB with Raspberry Pi OS 64-bit. |
Hey so it's fine if I close this pull request and @jumpy-badger open's his? @jumpy-badger is it finished? |
Added commit guidelines to CONTRIBUTING.md to aid people in writing proper commits.
As part of the base enemy mech script its faction should be updated to 4 to make sure it's seen as an enemy by the client. The AgDarklingMech script has been deleted as its functionality was essentially that of BaseEnemyMech and thus no longer necessary.
Added issue templates to aid with the structural submission of issues.
When applied this commit updates the code style used when validating coin pickups.
…n tokens for 25 maelstrom infected bricks
Adds the ability for the buccaneer valiant to spawn a ship that rams enemies and smashes them. Next to a script that triggers the ship skill a few other changes had to be made: - Force movement behavior server side calculation and sync - The ship has no physics volume so the FindValidTargets for behaviors had to be altered to allow ControllablePhysics entities to find entities within their area. The "target_self" AOE flag has been used to replicate the old behavior.
This log was causing confusion and issues when in reality there was no problem present.
- Added debug logging - Created vLog, a root function for all log functions - Placed failed to load script log under this new LogDebug function - Updated included config functions
When applied this commit fixes the unix build of the previous dLogger PR. This commit also fixes backwards compatability with config files.
could be the cause of long-soak (hours long) sessions having CPU issues
Okay we're not merging this for sure. I don't know how I managed to screw up that commit history. @jumpy-badger you can take it from here. |
I've got a few more changes to push to the branch. Will make a pull request once that's done |
Opened a draft pr to get the ball rolling as the friends list is currently crashing the chatserver when someone accepts a request #231 Feel free to push any changes/fixes |
Added support for arm processors for DarkflameServer.
Tested on a Raspberry Pi 4 8gb (Ubuntu 20.04 LTS).