Skip to content
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

Closed
wants to merge 26 commits into from

Conversation

mixy1
Copy link

@mixy1 mixy1 commented Dec 8, 2021

Added support for arm processors for DarkflameServer.
Tested on a Raspberry Pi 4 8gb (Ubuntu 20.04 LTS).

@codeshaunted
Copy link
Member

Even if this compiles, do you have a MySQL connector library for ARM?

@mixy1
Copy link
Author

mixy1 commented Dec 8, 2021

I wrote in the readme. The ubuntu repositories have the library libmysqlcppconn-dev compiled for aarch64
that is obtained as such
sudo apt-get -y install libmysqlcppconn-dev.
In fact in the CMakeLists.txt I depend on the fact that the server hoster has downloaded and installed the package onto their system.
tl;dr
CMakeLists.txt appends /usr/include/ to the include path
And also uses the mysqlcppconn in the link_libraries function.

@codeshaunted
Copy link
Member

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?

@jumpy-badger
Copy link
Contributor

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.

@mixy1
Copy link
Author

mixy1 commented Dec 8, 2021

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.
Maybe I should add the version to the apt-get install command? The other option I could see is adding the source and building from source like what the patch mentioned above is doing.

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 🤷‍♂️.

@codeshaunted
Copy link
Member

Would probably be good to add a section to the README about ARM builds.

@mixy1
Copy link
Author

mixy1 commented Dec 8, 2021

It's added in my patches.

@jumpy-badger
Copy link
Contributor

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've updated my branch and it should be ready now, is it worth pull requesting that?

@mixy1
Copy link
Author

mixy1 commented Dec 8, 2021

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.

@mixy1
Copy link
Author

mixy1 commented Dec 8, 2021

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.

@jumpy-badger
Copy link
Contributor

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.

@codeshaunted
Copy link
Member

codeshaunted commented Dec 9, 2021

Honestly it is probably a better solution to drop standard MySQL support entirely and opt for MariaDB… @DarwinAnim8or @Wincent01 @MickVermeulen thoughts?

@MickVermeulen
Copy link
Contributor

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.

@mixy1
Copy link
Author

mixy1 commented Dec 10, 2021

If we compile from source we shouldn't have to drop support for any platform though?

@MickVermeulen
Copy link
Contributor

Fair enough, how are the build times for that?

@mixy1
Copy link
Author

mixy1 commented Dec 10, 2021

Building only mariadb-connector-cpp on a raspberry pi 4 8gb
make -j4
real    3m39.490s
user    12m47.063s
sys     1m3.167s

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).
On another note I don't see why M1 mac shouldn't be supported after this patch.
Also we should merge @jumpy-badger's patch not mine as mine does not have mariadb.

@MickVermeulen
Copy link
Contributor

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.

@jumpy-badger
Copy link
Contributor

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?

@MickVermeulen
Copy link
Contributor

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.

@maxonary
Copy link

maxonary commented Dec 14, 2021

I can approve this script compiles on a RPI 4 8GB with Raspberry Pi OS 64-bit.

@mixy1
Copy link
Author

mixy1 commented Dec 14, 2021

Hey so it's fine if I close this pull request and @jumpy-badger open's his?

@jumpy-badger is it finished?

mixy1 and others added 7 commits December 14, 2021 17:19
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.
Daystar1998 and others added 18 commits December 14, 2021 17:21
When applied this commit updates the code style used when validating coin pickups.
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
@mixy1 mixy1 closed this Dec 14, 2021
@mixy1
Copy link
Author

mixy1 commented Dec 14, 2021

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.

@jumpy-badger
Copy link
Contributor

I've got a few more changes to push to the branch. Will make a pull request once that's done

@jumpy-badger
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.