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.
Maybe this patch from alpine addresses your problem: http://git.alpinelinux.org/cgit/aports/tree/community/go/default-sc-getpw-r-size-max.patch
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".
The alpine package http://git.alpinelinux.org/cgit/aports/tree/community/go-bootstrap 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?
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) summary: - 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
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. Thanks, William
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 https://github.com/GregorR/musl-gcc-patches/blob/master/gcc-config-musl.diff (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...
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?
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.
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?
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.
