Armv7 / Raspberry PI

[DaveSophoServices]

Is your feature request related to a problem? Please describe. I'm wanting to compile orchidd for raspberry pi. I've got the docker env setup, running bash, instead of the setup-dkr.sh. Then, running 'make srv-lnx',

make[1]: Entering directory '/mnt/srv-shared'
make[1]: *** No rule to make target 'out-lnx/armv7l/orchidd', needed by 'all'.  Stop.
make[1]: Leaving directory '/mnt/srv-shared'
makefile:44: recipe for target 'srv-lnx' failed
make: *** [srv-lnx] Error 2

Describe the solution you'd like what files do I need to write/add to get this to work?

Describe alternatives you've considered I copied the srv-shared/out-lnx/x86_64 folder to armv7l, and updated folder names in there (such as the c include path), but that didn't solve the problem :-)

[saurik]

So this is way harder than you'd expect, as I have a ton of dependencies I've somewhat manually configured as part of some (exciting!) server work I'm in the middle of and I haven't built out an abstraction for architectures yet :(. I've been working on getting 64-bit ARM support as a beachhead of such for the client, but I hadn't even considered that someone would (certainly right now ;P) be trying to run the server on non-Intel for a number of reasons (...and there are even some upcoming hardware requirements I'm considering that might make running it on a Raspberry Pi somewhat awkward). That all said, I'd love to talk to you more at some point about your interests here, and might be able to provide some support for this... in a few weeks? (Is that cool?)

[saurik]

Ok, so I forgot that I had actually finished the 64-bit ARM client support, which means I have more finalized infrastructure than I thought. Maybe I'll have this working for you this weekend.

[DaveSophoServices]

Hm, I'm not running 64-bit ARM. It's the 32bit OS version. Does this mean we're not going in the 32bit arm direction? It looks like the raspberry pi folks are not really pushing the 64bit version of their OS, I don't think it's out of beta so there are a whole tonne of 32 bit rasp pis.

$ sudo lshw 
pi.xx.x            
    description: ARMv7 Processor rev 3 (v7l)
    product: Raspberry Pi 4 Model B Rev 1.4
    serial: 100000005eaa8824
    **width: 32 bits**
    capabilities: smp

[saurik]

The fact that I finished the aforementioned 64-bit ARM support means that I have more finalized infrastructure for multi-architecture builds than I thought; my sentence would have meant the same thing if I had said "MIPS" there, knowing full well you are working with 32-bit ARM. (That said, I just ran into an actual roadblock with getting the server to compile for 32-bit ARM in that I'm going to need to figure out how to compile the host-side generation parts of this for 32-bit Intel for my iterative testing here as one of my dependencies doesn't support building a 32-bit target on a 64-bit host :/.)

That all even further said, I do want to remind that it is quite possible I will consider a Raspberry Pi (or maybe actually any 32-bit device, for a different reason) to not be a viable place to run the Orchid server going forward, but it seems fun enough to have the build environment be general enough to at least temporarily target it (but I'm not going to "support" that target in any real way--particularly not with respect to offering releases or documentation--until I have a much better understanding of a few things I'm working on, as I might have to retract entirely the ability to run the server on such a device).

[saurik]

The next release of Orchid, though, will definitely now have a 32-bit ARM client daemon available (and code will be pushed to master after I finish debugging the CI and get a fully clean build).

[saurik]

@DaveSophoServices OK! If you now do make machine=armhf in srv-shared I believe you should get binaries that will at least pretend to run on your Raspberry Pi... note that I haven't actually tried running them myself as I don't have a 32-bit ARM device ;P. (Also: I haven't added anything to the top-level build for this, as I'm not yet sure if it should be an officially supported target; that top-level build is really only intended for complete releases: I'd say you should go into srv-shared and do builds from there.)

[saurik]

(You can also download binaries from the build artifacts of the CI, but that's maybe not as much fun.)

[DaveSophoServices]

I've tried running the make, and I get the following:

srv-shared# make machine=armhf
clang++ -stdlib=libc++ -c -std=c++11 -o out-lnx/protobuf/any.o -DHAVE_PTHREAD -I./p2p/protobuf/src -Isrc p2p/protobuf/src/google/protobuf/any.cc
In file included from p2p/protobuf/src/google/protobuf/any.cc:31:
./p2p/protobuf/src/google/protobuf/any.h:34:10: fatal error: 'string' file not
      found
#include <string>
         ^~~~~~~~
1 error generated.
p2p/protobuf.mk:27: recipe for target 'out-lnx/protobuf/any.o' failed
make: *** [out-lnx/protobuf/any.o] Error 1

I'll look for the prebuilt artifacts :-)

[saurik]

clang++ -stdlib=libc++ -c -std=c++11 -o out-lnx/protobuf/any.o -DHAVE_PTHREAD -I./p2p/protobuf/src -Isrc p2p/protobuf/src/google/protobuf/any.cc

So, note the command that was being run there: it wasn't even cross-compelling; it was just trying to compile a simple tool for your local machine as part of the build phase, and the file you are missing is from the standard library... you simply don't have a fully working clang installation (in specific, you are missing libc++). You can either do the usual dance of "install the things you are missing as they cause the build to fail" (that's what I would do) or install all the things in env/setup-lnx.sh (which does have libc++) as a baseline.

[DaveSophoServices]

Oh, I see... Thanks for explaing that part :-)

I found a CI artifact and that executes. I'm not going to figure out how to make it run :-) Thanks for your work!