Bug 221297 - lang/go: Fix arm build
Summary: lang/go: Fix arm build
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm Any
: --- Affects Some People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: easy, needs-qa
: 231436 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-08-07 05:45 UTC by Hiroki Tagato
Modified: 2018-11-11 19:59 UTC (History)
10 users (show)

See Also:
bugzilla: maintainer-feedback? (jlaffaye)
koobs: merge-quarterly?


Attachments
A patch for Makefile (293 bytes, patch)
2017-08-07 05:45 UTC, Hiroki Tagato
no flags Details | Diff
Updated patch (550 bytes, patch)
2017-09-11 11:10 UTC, Hiroki Tagato
koobs: maintainer-approval+
Details | Diff
Build log WITHOUT CGO_ENABLED=1 (20.04 KB, text/plain)
2017-09-11 11:11 UTC, Hiroki Tagato
no flags Details
Build log WITH CGO_ENABLED=1 (22.27 KB, text/plain)
2017-09-11 11:12 UTC, Hiroki Tagato
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hiroki Tagato 2017-08-07 05:45:28 UTC
Created attachment 185109 [details]
A patch for Makefile

Crossbuilding of lang/go (using Poudriere) ends up with the following error:
=======================<phase: package        >============================
===>  Building package for go-1.8.3,1
pkg-static: Unable to access file /wrkdirs/usr/ports/lang/go/work/stage/usr/loca
l/go/pkg/freebsd_arm/runtime/cgo.a:No such file or directory
*** Error code 1

According to the Go source code at https://github.com/golang/go/blob/master/src/go/build/build.go#L307, "cgo must be explicitly enabled for cross compilation builds".

I tried attached the patch and crossbuilding succeeded without an error.
(GOARM=7 is to cope with the bug #205820)

I'm not sure how I can know host arch of crossbuilding (target arch is ${ARCH}), so I just simply put the line there, which should be better only when crossbuilding.

Thanks,
Hiroki Tagato
Comment 1 Hiroki Tagato 2017-09-11 11:09:01 UTC
My initial comment "cross-building of go requires explicit GCO_ENABLED=1" was a misconception. It was not a cross-building but an emulated-building (by Poudriere/Qemu user-mode emulation). So please disregard my first comment.

However, explicit "CGO_ENABLED=1" still seems necessary even when native-building.

I tried to build go 1.9 on a Raspberry Pi 2 (11.1-RELEASE) and the build ended up with the following message (The full log is attached go-1.9,1-without-cgo-enabled.log):

====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
===> Checking for items in pkg-plist which are not in STAGEDIR
Error: Missing: go/pkg/%%opsys_ARCH%%/runtime/cgo.a
===> Error: Plist issues found.
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/go
====>> Error: check-plist failures detected

Applying the patch (lang-go.diff) make the build succeed. The successful build log is go-1.9,1-with-cgo-enabled.log.

P.S. GOARM=7 is also necessary on RPI2 environment.

Thanks,
Hiroki Tagato
Comment 2 Hiroki Tagato 2017-09-11 11:10:50 UTC
Created attachment 186252 [details]
Updated patch
Comment 3 Hiroki Tagato 2017-09-11 11:11:35 UTC
Created attachment 186253 [details]
Build log WITHOUT CGO_ENABLED=1
Comment 4 Hiroki Tagato 2017-09-11 11:12:12 UTC
Created attachment 186254 [details]
Build log WITH CGO_ENABLED=1
Comment 5 Christopher Hall 2017-10-25 03:58:23 UTC
I had to add these environment values to be able to build a working go compiler on RaspberryPi FreeBSD 12.0-CURRENT #0 r323985 2017-09-26 snapshot.
Without the above patch none of the C interface libraries would compile.

During the build of the lang/go14 bootstrap tool I noticed some errors like:
"-t not found"
because its build script has some bash specific code.  I did patch the lang/go14 to use "/usr/local/bin/bash make.bash" before I built go 1.9.  I do not know
if leaving lang/go14 unchanged would produce a working go-1.9.  All compiles were done on Raspberry Pi, no cross compile used.
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2018-03-15 14:48:11 UTC
I can confirm that the GOARM=7 patch is necessary.  I had not seen this PR before, so I came up with the patch independently.  However, my build does fail with a plist error.

I will try it again with the full patch.
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2018-08-06 05:28:42 UTC
Comment on attachment 186252 [details]
Updated patch

Approved by: portmgr (maintainer timeout, 11+ months)
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2018-08-06 05:29:12 UTC
Open to take
Comment 9 mikael.urankar 2018-08-06 06:57:56 UTC
fwiw, mmel@ has a patch: http://build.humusoft.cz/patches/lang/go/go.diff
Comment 10 Julien Laffaye freebsd_committer 2018-08-08 21:13:08 UTC
Is this patch submitted to upstream ?
Comment 11 Hyun Hwang 2018-09-19 20:46:52 UTC
*** Bug 231436 has been marked as a duplicate of this bug. ***
Comment 12 Yuval Pavel Zholkover 2018-09-23 16:42:23 UTC
Hi,

I maintain the FreeBSD/arm builder, I just wanted to add some quick notes:

As per https://golang.org/doc/install/source#go14, when go 1.4 is used as the bootstrap toolchain, you must set CGO_ENABLED=0.
Also it's recommended to use https://dl.google.com/go/go1.4-bootstrap-20171003.tar.gz or the git branch release-branch.go1.4 directly.
In release-branch.go1.4 CGO_ENABLED=0 is set by default since:
https://github.com/golang/go/commit/94221a06124fe0d0f7ed45a355c72e46ed0e891b.

GOARM=7 is required when running on a multi-core processor. This is because the dmb instruction is used for memory barriers in various points, and it is an ARMv7 instruction (the ARMv6 variant "mcr p15, 0, %0, c7, c10, 5" was deemed too slow and wasn't used).
The check is performed at _runtime_, the dmb instruction is always compiled in.
For GOARM < 7 the dmb instruction is skipped as it is assumed to be single-core system - this is tested at startup and you get the "runtime: this system has multiple CPUs and must use atomic synchronization instructions. Recompile using GOARM=7." message otherwise.
Comment 13 Steve Wills freebsd_committer 2018-10-19 12:17:46 UTC
I've tested this and it doesn't build in poudriere via qemu for some reason that I haven't figured out, but it does build on the native hardware. Can we go ahead and commit this?
Comment 14 Yuval Pavel Zholkover 2018-10-19 16:24:23 UTC
(In reply to Steve Wills from comment #13)
Are you using poudriere via qemu on a 64-bit host by any chance?
It could be due to:
https://github.com/golang/go/issues/25770
Comment 15 Steve Wills freebsd_committer 2018-10-19 19:12:34 UTC
(In reply to Yuval Pavel Zholkover from comment #14)
Yep, qemu running on amd64.
Comment 16 Victor hooi 2018-11-09 05:23:21 UTC
I'm trying to understand this bug.

To confirm - this is to get Go working on ARM64, right?

And this will allow Go packages like Telegraf to work on ARM64, right

I'm trying to use Telegraf in order to pull metrics on pfSense:

https://www.reddit.com/r/PFSENSE/comments/8ufp0x/cant_find_telegraf_package_sg3100_pfsense_243/

However, the issue is that pfSense is based on FreeBSD, and this is running on the Netgate SG-3100 (which is ARM64). Hence, Telegraf isn't available as a package.

How far away is this bug from being fixed?
Comment 17 mikael.urankar 2018-11-09 10:49:24 UTC
(In reply to Victor hooi from comment #16)
No it's for armv6/armv7.
Comment 18 Victor hooi 2018-11-09 19:15:56 UTC
Sorry, I was incorrect before - I think the SG-3100 might actually be ARM7 (according to https://www.netgate.com/solutions/pfsense/sg-3100.html).

So I guess this fix would cover it.

However, is it quite a long way off, or is it close?
Comment 19 Yuval Pavel Zholkover 2018-11-11 19:59:13 UTC
I think you should commit the patch as is, the poudriere failure is due to wrong qemu-user emulation. I highly doubt it will be addressed upstream in Go.