zLib link failures on Xenial
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
golang-1.13 (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[impact]
Applications that use the "compress/zlib" package fail to build.
[test case]
$ cat > go.mod
module github.com/foo/baz
go 1.13
$ cat > main.go
package main
import (
"bytes"
)
func main() {
var b bytes.Buffer
w := zlib.NewWriter(&b)
w.Close()
}
$ go build -v
The final command will fail before this is fixed and pass after.
[regression potential]
The fix is just preventing debhelper from stripping the zlib.a file in golang-1.13-go. Rebuilding the go toolchain one more time should not introduce any changes (the go project is pretty good about bootstrap hygiene).
[original description]
Backported go-1.13 came with issues with zlib.
In some projects i see link errors:
golang.
github.
github.
github.
...
also reported in https:/
and compiling a trivial program (example from compress/zlib reference) causes crash during linking:
root@a6a24cdee4
module github.com/foo/baz
go 1.13
root@a6a24cdee4
package main
import (
"bytes"
)
func main() {
var b bytes.Buffer
w := zlib.NewWriter(&b)
w.Close()
}
root@a6a24cdee4
go version go1.13.8 linux/amd64
root@a6a24cdee4
DISTRIB_ID=Ubuntu
DISTRIB_
DISTRIB_
DISTRIB_
root@a6a24cdee4
# github.com/foo/baz
panic: runtime error: index out of range [23] with length 0
goroutine 1 [running]:
cmd/link/
cmd/link/
cmd/link/
cmd/link/
cmd/link/
main.main()
description: | updated |
Huh this is very strange. I notice that go build -a succeeds so I wonder if one of the .a files that's part of golang-1.13-go is broken somehow?