Go packages (rclone and syncthing) on older MIPS kernel

alllexx88 commented 6 years ago

Hi, seeing some closed issues (at least #857), I understand you're already aware of the problem. MIPS TomatoUSB, for example, is running a 2.6.22.19 kernel, which is apparently too old for current Go. e.g., running Entware-ng syncthing produces this error:

[root@unknown opt]$ syncthing
[monitor] 12:56:24 FATAL: stderr: pipe: function not implemented

and trying to list files using rclone gives this:

[root@unknown opt]$ rclone ls dropbox:
2018/01/23 12:47:55 ERROR : : error listing: Post https://api.dropboxapi.com/2/files/list_folder: dial tcp: lookup api.dropboxapi.com on 127.0.0.1:53: dial udp 127.0.0.1:53: errno -9
2018/01/23 12:47:55 Failed to ls: Post https://api.dropboxapi.com/2/files/list_folder: dial tcp: lookup api.dropboxapi.com on 127.0.0.1:53: dial udp 127.0.0.1:53: errno -9

The pipe error has a workaround on Optware-ng: see mips_no_pipe2.patch at https://github.com/Optware/Optware-ng/tree/master/sources/golang

The net.Listen error (rclone error from above) is trickier, I don't know of a workaround for it yet (see https://github.com/golang/go/issues/23446).

Now, the (maybe) interesting part.

Optware-ng syncthing and rclone MIPS packages are built using gccgo: though it's a bit hacky to achieve, the resulting packages work fine on 2.6.22.19 kernel. In case you're interested in details, I'm using the following for this:

ordinary Go (1.10beta2 in my case, for MIPS softfloat support)
cross gccgo from gcc-7.2.0 toolchain
static host gcc-7.2.0 with go (gccgo and gotools). I do a little patching to build gotools (add -lpthread link flag) and use a gccgo wrapper that invokes $0.real "$@" -lpthread, since (static) libgo uses symbols from libpthread, and compiling Go code fails without the flag (I use host gccgo to bootstrap Go)

And this is how I build rclone and syncthing:

Build and install .../vendor/golang.org/x/sys/unix with ordinary Go with -compiler gccgo switch: using go from gcc gotools skips building gccgo_c.c, which leads to multiple undefined references to gccgoRealSyscall
Then build the rest with go from gcc gotools

(With syncthing I'm patching build.go for this)

See rclone.mk and syncthing.mk for the reference.

What do you think about this?

zyxmon commented 6 years ago

We have used gccgo a year ago - https://github.com/Entware-ng/Entware-ng/commit/52674535d1bd02820da75dd652db15251887361b#diff-a2940e5596906c384dcd1e882c6131fe I have switched development to google go compiler (it supports mip & mipsel now) and prefer to build entware for modern kernels - https://github.com/Entware-for-kernel-3x/Entware-ng-3x Old kernels give a lot of headache. We had a working gccgo syncting package for mipsel some time ago (2016) - http://forums.zyxmon.org/viewtopic.php?f=5&t=5376

alllexx88 commented 6 years ago

Old kernels give a lot of headache.

Agree 100%. Unfortunately, some platforms are stuck with 2.6.22.19 on MIPS, like Broadcom platforms, which have some closed-source kernel modules.

ryzhovau commented 6 years ago

I see no sense to add heavy packages (including GO packages) for relative weak MIPS devices, sorry.

alllexx88 commented 6 years ago

@ryzhovau I don't quite agree that my RT-N66U with 600MHZ CPU and 256 MB RAM is weak. syncthing is heavy on RAM, but adding swap makes it usable. But I respect your choice. Thanks

Entware / Entware-ng

Go packages (rclone and syncthing) on older MIPS kernel #860