Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 571700

Summary: dev-lang/go and dev-lang/go-bootstrap 1.4.x: Build fails due to warnings on musl
Product: Gentoo Linux Reporter: toast+misc
Component: [OLD] DevelopmentAssignee: William Hubbs <williamh>
Severity: normal CC: blueness
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---
Bug Depends on: 448590, 573322    
Bug Blocks:    

Description toast+misc 2016-01-12 20:44:31 UTC
dev-lang/go-1.4.2 and dev-lang/go-bootstrap-1.4.2 fail their builds after the following warnings:

os/user/lookup_unix.go:64: cannot use C.ulong(bufSize) (type C.ulong) as type C.size_t in argument to _Cfunc__CMalloc
os/user/lookup_unix.go:73: cannot use C.ulong(bufSize) (type C.ulong) as type C.size_t in argument to _Cfunc_getpwnam_r
os/user/lookup_unix.go:88: cannot use C.ulong(bufSize) (type C.ulong) as type C.size_t in argument to _Cfunc_mygetpwuid_r

However, the lines look more like so: C.malloc(C.size_t(bufSize)), bufSize being of type C.long.

Now in musl (and as far as I can tell, in GLibc as well), size_t is of type unsigned long int (specifically in musl, unsigned _Addr, _Addr being long). This means that the conversion to size_t was performed properly, but the system fails to notice that size_t and ulong are effectively the same type.

These warnings cause make.bash to return something other than 0, which in turn makes the ebuild proc its "|| die" statement.

It is notable that when manually compiled (git checkout go1.4.2), the resulting binary passes all tests (0 known bugs, 0 unexpected bugs).

I'm not entirely sure how to approach this issue (since I am not very experienced with Go). A short term solution would be to remove the || die, and potentially force the tests to run, parsing the output.
Comment 1 Felix Janda 2016-01-13 19:46:10 UTC
Maybe this patch from alpine addresses your problem:
Comment 2 toast+misc 2016-01-13 20:30:53 UTC
This patch is actually unrelated. The issue here is with the malloc call which expects size_t, and go fails to realize that ulong is the same as size_t.

The patch addresses a different problem (one that musl does not seem to be affected by).

The problem here seems to be with the ebuild: make.bash will return fail even on successful builds, as long as at least one warning was issued, and the ebuild (go-1.4.2, line 69) specifies ./make.bash || die "build failed".

Essentially it's a case of the ebuild expecting that non-zero return values means a categorical fail, while the script returns non-zero if even a single warning is issued.

One can verify that the resulting binary is fine by running the tests, so it's really a case of different sensitivities. The fix needed would be against the ebuild, to detect a failed build otherwise (maybe checking for the existence of bin/go?)

tl;dr - patch is unrelated (alpine does not have any patches for this, I've tried applying it and running ./make.bash || echo FAIL just in case, it does indeed still "fail"), seems to be build system weirdness, no clue how the alpine variant runs (it's in the community repo, so who knows).

I'll have a read through make.bash and see if I can come up with anything more sophisticated than just "check to see if the go binary exists after build".
Comment 3 Felix Janda 2016-01-14 07:27:49 UTC
The alpine package

was in "main" not too long ago (version 1.4.2), and it checks for
the exit status of ./make.bash. It seems to have worked.

I can reproduce the bug on arm, but with "ulong" being replaced by
"uint" (since _Addr=int).

Since you have successfully bootstrappped go: Does the real cgo
also complain about these conversions?
Comment 4 toast+misc 2016-01-14 20:18:05 UTC
go 1.4.2:
- exhibits the warnings (make.bash returns 2), produces the executable anyway
- runs through the tests, fails once (os/user [build failed]) (returns 2)
- passes all tests from test/run (no longer a thing in 1.5.x) (returns 0) ("0 known bugs, 0 unexpected bugs")

go-bootstrap (from 1.5.2, go-linux-amd64-bootstrap, built using 1.4.2):
- exhibits the warnings (make.bash returns 2), produces the executable anyway
- runs through the tests, fails several (returns 2)

go 1.5.2 (using built go 1.4.2 above):
- exhibits the warnings (make.bash returns 2), produces the executable anyway
- runs through the tests, fails several (returns 2)

- all builds complain about the typing mismatch
- all 1.5.x based builds fail multiple tests
- 1.4.x based builds pass test/run tests, fail single (related) run.bash test
Comment 5 William Hubbs gentoo-dev 2016-01-16 17:26:01 UTC
Once dev-lang/go-1.5.3 and dev-lang/go-bootstrap-1.4.3 are stabilized, all earlier versions of dev-lang/go will be removed, so I need to know the status of these versions to determin what to do.


Comment 6 Felix Janda 2016-01-16 19:05:51 UTC
The root cause seems to lie in the fact that we do not apply the musl
gcc patches (unlike every other distro using musl, why?).

In particular, we do not apply

(but something similar). For the problem with go, the patch to
stddef.h is relevant. (You can test without reinstalling gcc by
directly patching /usr/lib/gcc/$HOST/$VERSION/include/stddef.h.)

Without the patch musl's headers and gcc's internal stddef.h both
typedef size_t, which does not seem to be a problem except that the
generated DWARF debug information is slightly differnt. And cgo
relies on this DWRF debug information...
Comment 7 William Hubbs gentoo-dev 2016-01-24 14:44:34 UTC
This is for go-1.4.2, so it may not be relevant any more once
go-bootstrap-1.4.3 and go-1.5.3 hit stable.

Can someone please test with those versions and let me know?
Comment 8 toast+misc 2016-01-24 21:23:24 UTC
Can confirm:
Go-Bootstrap 1.4.3 fails with the same issue.
Can't test in-tree Go 1.5.3, seeing as the bootstrap fails.
Comment 9 Felix Janda 2016-01-29 18:16:03 UTC
There is now gcc-4.9.3-r999 in the musl overlay which has the fix for
stddef.h. Could you try bootstrapping go with that?
Comment 10 toast+misc 2016-01-30 05:58:02 UTC
Confirming that with gcc-4.9.3-r999 the problem is solved, which also confirms that this is a case of gcc requiring more patches than the -r99 version provides. Potentially worth putting this into the musl wiki or similar.