enable softfloat on MIPS arch

[sedlund]

What is the purpose of this change?

MIPS does not have a floating point unit. The binaries built for MIPS do not run on devices that do not have MIPS_FPU enabled in kernel. Enabling GOMIPS=softfloat makes them work.

Was the change discussed in an issue or in the forum before?

Unsure

Checklist

• I have read the contribution guidelines.
• I have added tests for all changes in this PR if appropriate.
• I have added documentation for the changes if appropriate.
• All commit messages are in house style.
• I'm done, this Pull Request is ready for review :-)

[Cnly]

Hi @sedlund, it seems the GOARCH value you defined (MIPS) is not in https://golang.org/doc/install/source#environment. Can you confirm it is working for the target devices? Thanks!

[sedlund]

sorry, I messed up the case of the GOARCH target. Updated, tested make compile_all. Binary for linux/mips works on my mips based device.

probably need to enable for mipsle as well (#2725) . I do not have a device to verify with though.

[ncw]

@sedlund this looks useful thank you :-)

• Do you know what the consequences of enabling "softfloat" are? Does it mean that processors with floating point processors will use emulation?
• I think it would be a good idea to do mipsle also
• can you go fmt the file to fix the build please?

[sedlund]

1. From my understanding of patches from runtime: mips32 soft float point support golang/go#18162 it seems the softfloat flag causes the compiler to emit code that does not use hardware FPU. Which I think is different from emulation, as it is not translating calls, but using separate functions in place of the ones utilizing FPU.
2. Added softfloat for mipsle
3. Ran go fmt - travis passed, AppVeyor might have some other problem?

[ncw]

1. From my understanding of patches from golang/go#18162 it seems the softfloat flag causes the compiler to emit code that does not use hardware FPU. Which I think is different from emulation, as it is not translating calls, but using separate functions in place of the ones utilizing FPU.

Fine, I think we can live with that as rclone isn't a heavy FPU user (just used for a few stats).

2. Added softfloat for mipsle

Thanks

3. Ran go fmt - travis passed, AppVeyor might have some other problem?

Yes the AppVeyor build is broken for different reasons!

I can't merge this using the github UI :-(

This branch cannot be rebased due to conflicts
Rebasing the commits of this branch on top of the base branch cannot be performed automatically due to conflicts encountered while reapplying the individual commits from the head branch.

I'm not sure what is causing the conflict - I think it is the merges you did. Merges in pull requests always seem to cause problems at github..

So can you squash your branch down to one commit, rebase it on master and force push it? That should allow me to merge cleanly and as a bonus it will pick up the fix for the AppVeyor CI!

Thanks

[Cnly]

probably need to enable for mipsle as well (#2725) . I do not have a device to verify with though.

Just confirmed on a mipsle device provided by @tony-sunjian:

$ ./rclone -V
rclone v1.44-042-g4a6cfbeb-patch-1-beta
- os/arch: linux/mipsle
- go version: go1.11.2

[sedlund]

I think I defeated git finally. :) Let me know if it works for you.

[ncw]

You win your epic battle with git 🏆

Thank you very much. I'll merge that now :-)