Compilation using Buildroot fails with: build constraints exclude all Go files


I started to write a package definition for buildroot:

However, the compilation fails with:

can't load package: package build constraints exclude all Go files in /[...]/build/syncthing-1.13.1/_gopath/src/

In my initial research I came to the conclusion that it might be related to CGO: cmd/go: give a better error message when building Go package with CGO_ENABLED=0 · Issue #24068 · golang/go · GitHub

However, activating CGO as mentioned in the buildroot documentation does not solve my problem.

Until now, nobody could help me at the buildroot mailing list. Therefore, any hints how I could track down the issue would be highly appreciated, as I never used GOLANG before.


I don’t know, but the error mentions gopath which is a build method we haven’t used in a couple of years. I’d suggest you get it building locally first using our build instructions, to make sure you understand how it works, and then try to accomplish the same thing in buildroot, whatever that is.

Did you see Building Syncthing — Syncthing v1 documentation?

I haven’t looked at your packaging, but that error usually happens in you just try to do go build . or go build, which are wrong.

1 Like

Thanks for the hints.

@imsodin You are right, this was the standard way provided by buildroot. I tried to go step by step as @calmh suggested, and it compiles:

$ go run build.go -arch arm build

But Buildroot sets the architecture as environment variable, which fails:

$ GOARCH=arm go run build.go build
fork/exec /tmp/go-build567270573/b001/exe/build: exec format error

I thought that the command line parameter and the environment variable are interchangeable.

I thought

It’s not, because the latter instructs the go compiler to build the build script for arm and then run it, which fails if you’re not on arm.

Ah, thanks. Is it possible to instruct build.go to just create the host build script and thereafter I manually trigger the host build script to build the target binary? With this I can use different environments as mentioned here.

As I don’t want to just find a solution for myself but provide the results also to mainstream.

Thanks, Sven

No idea what “mainstream” is and what its requirements are, and without that information one cannot answer that. There’s two general approaches: Do it our way, i.e. use build.go how it’s supposed to be used, or redo whatever build.go does in whatever build-system your “mainstream” uses. Basically build.go is our “makefile”.

Sorry, I made a mistake: I wanted to say “upstream” and I meant that I want to create a Syncthing package for Buildroot which is integrated into their official repository.

I got Syncthing compiled using build.go by hand and I do not put this approach into question. I want to integrate it into the Buildroot-Toolchain. As far as I understood I have two different environments in Buildroot: one host and one target environment and thus I want to execute build.go in two stages. Something like this:

$(GO_HOST_ENV) $(GO_BIN) run build.go build --stop-after-creating-build-script
$(GO_TARGET_ENV) newbuildscript -arch arm --continue

OK, I guess you just realized that this is my first contact with go :roll_eyes:

Its seems to be that simple:

$(GO_HOST_ENV) $(GO_BIN) build build.go
$(GO_TARGET_ENV) ./build -goarch arm
1 Like

Or even simpler: $(GO_BIN) run build.go -goarch $(GO_TARGET_ENV).

Might be that variable contains multiple export commands. Anyway, if you use the env var, don’t also use the -goarch flag I think.

Thanks a lot. I got it compiled within Buildroot.

If have still an issue to get it upstream: “It is not desirable to have Go modules enabled in Buildroot in the normal case, as Buildroot manages downloading the sources, and third party dependency managers are typically not used.”

But this is definitely out of scope of this forum…

Again, thanks for your quick support!

1 Like

Not necessarily. If you can figure it out together with whoever works with Go in Buildroot then that’s great of course. However I hope I didn’t give the impression that I don’t want any packaging questions here. I’d just like to have an overview of the relevant information here in the forum (what’s the problem/requirement, …), and not having to search for them in linked email threads. So if needed, now or in the future, feel free to explain what the problem is with modules and maybe we can help :wink: