Closed ElonH closed 4 years ago
To address your specific question first, if you really want to change CGO_ENABLED
, you can override GoPackage/Environment
in your Makefile (after including golang-package.mk). You can either take the output of GoPackage/Environment/Default
and filter it to modify CGO_ENABLED
only, or you can set a completely different GoPackage/Environment
.
Having said that, I don't think there is (yet) a valid use-case for making CGO_ENABLED
configurable, and I don't think disabling cgo is the right way to solve your issue.
The error you are seeing is happening in the external linker and is AFAICT unrelated to cgo. Disabling cgo happens to "fix" your issue because by disabling cgo, go then decides to use its built-in linker instead of the external linker. (Because you have set GO_PKG_LDFLAGS_X
, the default ldflags, which instructs go to always use the external linker, did not apply. #10874 fixes this.)
I'm still trying to figure out what the error is exactly and how to really fix it, so I don't have any good news for you yet, but I think fixing it is better than working around the problem.
I think I understand enough of the issue to explain what is happening:
rclone supports "out-of-tree" Go plugins. Their plugin system uses the plugin
package. (Go plugins are compiled with -buildmode=plugin
).
The plugin
package requires cgo but doesn't force it to be enabled. Stub functions are used when cgo isn't enabled; they throw errors instead of loading plugins.
-buildmode=plugin
isn't supported (yet) for linux/mips. If compiling plugins for mips isn't supported, then compiling an executable for mips that loads plugins probably isn't supported either.
I'm still not sure what is the exact cause of the link error, but I believe there is a conflict in the way Go is calling the external linker for dynamic linking (for the executable to load plugins at run-time) and how it is compiling objects for mips. (I get a very similar error if I add -znocopyreloc
to TARGET_LDFLAGS
just as the internal linker does when dynamic linking is used.)
So one way to avoid the link error is to disable cgo and use the internal (instead of external) linker. This has the indirect effect of disabling plugins.
Another way to avoid the link error (and what I suggest you do) is to patch out/delete this line to directly disable plugins. I've test compiled rclone with this and it works for me.
Also, you have PKG_VERSION:=1.49.5
and PKG_SOURCE_VERSION:=5d3323605080509cf53de5980443c6d02fd50a48
in your Makefile but rclone/rclone@5d3323605080509cf53de5980443c6d02fd50a48 is not 1.49.5 (that would be rclone/rclone@17c21aed5affa008f98970e17d15d5b2884f9888).
You can checkout the tag directly by setting PKG_SOURCE_VERSION:=v$(PKG_VERSION)
.
(I'm guessing you used a newer commit because it had fixes to work with Go 1.13, but labelling it as 1.49.5 isn't helpful.)
Hi @jefferyto,
Thank you very much for finding out the crux of problem. I have verified on my mips that delete line and it works.
But I'm better like disable cgo instead of patch out statement of plugin package import, because of not very much advantage of binary size. On the other word, their size are almost same(I don't know whether I missed something).Based on the above fact, the binary of cgo disable not need external link libs, that is what I want to choose cgo disable strategy.
When -buildmode=plugin
support on linux/misp, I will try to bring plugin
back to rclone.
Thank you to point out package version confusion.
This error is from my repo Rclone-Openwrt issue
Maintainer: @jefferyto
Description:
For cross compile Rclone, I have to manually set
CGO_ENABLED=0
in golang-package.mk. Otherwise, it would raise a link error in build for MT7621, see https://forum.openwrt.org/t/rclone-on-openwrt/10671/4And I check other go project AdGuardHome build script which also has similar variable
CGO_DISABLED=1
.Could provide a option that control CGO enable/disable that we can use in package which rely on
golang-package