syncthing: unable to compile syncthing (core) 0.14.28 with go 1.6
syncthing 0.14.28 introduces code that can’t be built with go 1.6. The following error occurs:
+ go run build.go -no-upgrade build syncthing
WORK=/tmp/go-build095818036
cmd/syncthing/usage_report.go:11:2: cannot find package "context" in any of:
/usr/lib/golang/src/context (from $GOROOT)
/builddir/build/BUILD/syncthing/_build/src/context (from $GOPATH)
/usr/share/gocode/src/context
The Go 1.7 Release Notes mention what might be the cause of the issue:
Go 1.7 moves the golang.org/x/net/context package into the standard library as context.
The new import style for the “context” package is used unconditionally, even though it’s not available as “context” prior to go 1.7 (but as “golang.org/x/net/context”).
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 19 (12 by maintainers)
In this case, intentional. We switched the minimum required compiler to 1.7 a couple of months ago, among other things to be able to use
context: https://forum.syncthing.net/t/minimum-supported-go-compiler-is-now-1-7/9361. We aim to support the previous Go version (i.e., 1.7 when 1.8 is current, etc.) but guarantee the latest only. This is, for what it’s worth, the same as the Go teams support of Go itself. (Only latest version is supported, but previous version will also receive security fixes.)(Also, pendantry: no such thing as “stable bugfix (only) releases” in Syncthing at the moment. They are all feature-and-bugfixes and the version numbering has no relation to compiler requirements. The version numbering only tells you when to expect one compiled syncthing to be incompatible with another.)
That’s true, yet our version still starts with a 0, which sadly means we can do breaking changes out of cycle. I agree it’s not ideal. Also, there might have been security fixes that the older versions did not receive, so being on the bleeding edge usually works for everyone’s benefit.
Firstly, these type of questions should go on the forum, as it’s not actually a bug or feature and was most likely done with intention. Secondly we’ve spent significant effort documenting everything and trying to have good useful docs. Given this question could have been answered by them, going forward please check the docs first
We only support building with the latest stable version of Go. See the dev guide: https://docs.syncthing.net/dev/building.html
That works! Thank you for sharing!
Indeed. Lets move any general discussion of development and distribution practices to the forum instead of the bug tracker, please.
I think this was already answered:
Yes, this is unfortunate, but such is often life with distributions. Debian stable ships Go 1.3.3… Go has a relatively quick development pace.
Can you not build go 1.8 as part of the syncthing build process offline?
I’m building “proper” RPM packages for fedora (and EPEL for RHEL7) - which means I have to build the packages from source and can’t use the provided pre-built binaries (for legal, security, etc. reasons).
So, when building a package for a particular distribution, I MUST use the appropriate build infrastructure (package builds are done in a container) AND I can only use the packages that are made available by that distribution (since they run isolated from the host system, and in fact, without internet access). In this case, I can only use a go 1.6 compiler for building “proper” syncthing packages, since that is the latest version of the go compiler that is available in fedora 24 and RHEL7 build environments.
And just for the record, I have go 1.8.1 on my machine (as that’s what is shipped with fedora 26 alpha). But that is irrelevant here, because - for the same reasons as above - I can’t just build the binary on my system and package it up for older distributions.
Is there a reason the toolchain is so old EPEL7? Could you not compile a newer toolchain using the existing toolchain?
Fair point.
Still, this means that I won’t be able to provide syncthing packages for EPEL7 and fedora 24 anymore.
I understand that it’s not “officially supported”. Nonetheless, building syncthing with go 1.6 worked fine up to (and including) the 0.14.27 release, and bumping the “effective” compiler requirement from go 1.6 to 1.7 (or, officially, even to 1.8) between stable bugfix releases only seems like bad practice. That’s why I reported this here as a bug - because I thought the dependency bump was the unintended result of an oversight during development.