Closed samsapti closed 2 years ago
Wow, thank you so much for this, quite a large change and a huge step forward! Have you tested this on ARMv8 etc. to ensure it works for platforms other than amd64? I unfortunately don't have any Pi's etc. lying around to test on.
@sethforprivacy I need to make a few small fixes first, but after that I have a Raspberry Pi I can test it on.
Also, what do you think about supporting 32-bit systems, should we do that? This includes ARMv7 and ARMv6. ARMv8, which is also called ARM64v8, is 64-bit.
@sethforprivacy Confirmed working on a Raspberry Pi 4B, built with --platform linux/arm64
:
@sethforprivacy It seems the CI fails on the ARMv7 (32-bit) build. Do you want me to remove it and only keep ARMv8 (64-bit)?. It says it can't find something related to Boost:
#24 701.2 CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
#24 701.2 Could NOT find Boost (missing: system filesystem thread date_time chrono
#24 701.2 regex serialization program_options locale) (found suitable version
#24 701.2 "1.71.0", minimum required is "1.58")
#24 701.2 Call Stack (most recent call first):
#24 701.2 /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
#24 701.2 /usr/share/cmake-3.16/Modules/FindBoost.cmake:2179 (find_package_handle_standard_args)
#24 701.2 CMakeLists.txt:960 (find_package)
#24 701.2
#24 701.2
#24 701.3 -- Configuring incomplete, errors occurred!
#24 701.3 See also "/monero/build/release/CMakeFiles/CMakeOutput.log".
#24 701.3 See also "/monero/build/release/CMakeFiles/CMakeError.log".
And some other erros as well.
Yeah, I wouldn't stress over 32-bit support as that's not a suitable platform for Monero nodes for the most part anyways as most ARMv7 SBCs lack AES support as well. ARMv8 is a big step forward and a huge blessin,g thank you so much for all of the time spent on this!
I'll do a full review today and likely squash + merge afterwards assuming I don't catch anything major.
Alright, I've removed linux/arm
(ARMv7) from the workflows. If 32-bit systems don't support those features, then it's weird that monerod
is even available for those platforms. They're officially supported in the Makefile
at least.
Should be ready for merging now.
Hey @theanonymousexyz I had to revert, this broke all amd64 images and for some reason I didn't even think to test that yesterday. Please open a new PR and I will more thoroughly test it out, not sure what it was that broke it but my gut tells me it's the actual monerod compilation step not having a set platform.
Hmm, that's weird. I tested the amd64
build on my system, where it worked fine. I'll take a look at it later today.
It broke all my own nodes overnight as well once they pulled the image, exit code 132
. I haven't had time to dig in further, though.
More here as well: https://github.com/sethforprivacy/simple-monerod-docker/issues/44
When I looked at the CMAKE script in the monerod repo, it looked like it automatically determines the architecture. But it might be because I removed -D BUILD_64=ON
when I tried adding 32-bit support.
TBQH I'm an absolute noob when it comes to CMAKE and I grabbed those args from an assortment of different places so that very well could be it.
I would think it wouldn't be required if the underlying arch is 64-bit, but I'm not sure at all.
TBQH I'm an absolute noob when it comes to CMAKE
Yeah me too haha. I'll try it out later.
This PR adds cross-compile support via Docker Buildx and fixes #21.
I've also fixed some indentation issues in the example
docker-compose.yml
file.