-
Notifications
You must be signed in to change notification settings - Fork 19
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
Platform support branch. #312
Comments
If we use the pr-applem1 branch from RandomX in mc_randomx, we'll have macOS support without issue; the library will also be ~6 months older than it currently is. That said, not only has no notable to us development happened in that time, it'd still be newer than our currently used commit. I'm personally hoping it's simply merged though and we can just update to the latest commit, |
macOS and Windows use case insensitive file systems. The folder is named Pylint. It's trying to import from pylint proper instead of our custom folder. |
For what it's worth, mc_lmdb expects msvc. |
8bf28f1 fixed the WalletDB test failing. I'm hoping to get the other part of that checklist item via updating LMDB. Running every test on it now. |
LMDB issues are all sorted. |
Notably, running the Consensus test still prints EDIT: It's Nim's system module. Apparently, a set is corrupted? I'm really not sure. |
The issue was the RandomXFlags enum. Updating it now. |
Updated mc_randomx, as well as the version of RandomX used, to solve all issues there. As far as macOS is concerned, it's solely the Python issues standing (and lack of choosenim which will not be considered a blocker). |
Updating the argon2-cffi dependency fixed that issue. Possible new issue of pylint throwing plenty of no-member and c-extension-no-member errors. |
ULimit didn't work properly, finding files 0 .. 9 and 10 if it exists, yet no others. Replaced it with a horrible shell execution which does work. |
Except for choosenim on m1 Macs, macOS should work without issue now. I'd like to merge the platform support branch on that basis, yet keep it around pending further development on Windows. While I would like Ubuntu 14.04 support, as it's still a supported LTS branch, I understand it's 7 years old and not something we may want to officially support. I'm also just tired of tedious tasks, hence why I want to revisit Windows at a later date. |
Tracking issue for https://github.com/MerosCrypto/Meros/tree/platform-support.
Ubuntu 18.04 and 20.04 should work without issue.
Arch Linux should work without issue.
macOS has several issues.
-z muldefs
is used due to our multiple Rust libraries. This flag doesn't exist on macOS and isn't needed.-framework WebKit
.CoreFoundation
,CoreGraphics
,CoreVideo
,ColorSync
, andAppKit
are also needed frameworks..so
file extension when not on Windows; macOS uses.dylib
. I'm curious which BSD uses as well.booting Meros causes26 (invalid data!)
to be printed which is another LMDB error.26 (invalid data!)
on macOS.And there may be more I have yet to find. I also needed to set a manual CPATH/LIBRARY_PATH so gmpy2 would build. I installed the dependencies with
brew install gmp mpfr libmpc
and it worked without issue, yet after rebooting, and deciding to rebuild on Python 3.8 instead of 3.9 as an experiment, I needed to set a CPATH for gmp and LIBRARY_PATH for all three...Windows hasn't been supported in ages. I have no idea if we'll want to go with msvc or mingw when we add support for it. While it'd be great to say "MS ecosystem! msvc!", I do remember msvc has some quirks, such as not supporting C99, and I believe horrible CMake integration. That said, the last system I tried on had so much development cruft it's hard to actually say. Multiple libraries only have Linux build instructions. We also don't support tracking file handles on Windows, so Meros will fail to build there as well.
The text was updated successfully, but these errors were encountered: