First Last Prev Next    This bug is not in your last search results.
Bug 1149638 - Go rpm package spec define NO_BRP_STRIP_DEBUG=true NO_BRP_AR=true to avoid sort.a(__.PKGDEF) sort.a(_go_.o): Unable to recognise the format of file: file format not recognized
Go rpm package spec define NO_BRP_STRIP_DEBUG=true NO_BRP_AR=true to avoid so...
Status: IN_PROGRESS
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Development
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Jeff Kowalczyk
E-mail List
:
Depends on:
Blocks:
  Show dependency tree / graph
 
Reported: 2019-09-05 15:32 UTC by Jeff Kowalczyk
Modified: 2020-02-19 08:55 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Kowalczyk 2019-09-05 15:32:23 UTC 
openSUSE Packaging for go1.13 which closely follows earlier version go1.12,
go1.11 etc, manifests a problem with using the go command to compile link
and run go programs. This problem is not present in upstream Go releases
and is specific to current openSUSE packaging.

$ cat test.go
package main

func main() {
        println("Hello world")
}

$ go build test.go
# command-line-arguments
/usr/lib64/go/1.13/pkg/tool/linux_amd64/link: dwarf: missing type: type.uintptr

$ go run test.go
# command-line-arguments
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x90 pc=0x5ba65f]

goroutine 1 [running]:
cmd/link/internal/ld.decodetypeSize(...)
        /usr/lib64/go/1.13/src/cmd/link/internal/ld/decodesym.go:79
cmd/link/internal/ld.(*Link).symtab(0xc0006f6000)
        /usr/lib64/go/1.13/src/cmd/link/internal/ld/symtab.go:696 +0x2b9f
cmd/link/internal/ld.Main(0x84bdc0, 0x10, 0x20, 0x1, 0x7, 0x10, 0x69aa6a, 0x1b, 0x697551, 0x14, ...)
        /usr/lib64/go/1.13/src/cmd/link/internal/ld/main.go:239 +0xc91
main.main()
        /usr/lib64/go/1.13/src/cmd/link/main.go:65 +0x1d6
Comment 1 Jeff Kowalczyk 2019-09-05 16:47:49 UTC 
Note that go1.13 is currently only packaged in devel:languages:go and has not yet been submitted to Factory or elsewhere.
Comment 2 Jeff Kowalczyk 2019-10-23 20:44:33 UTC 
Change title from:
go1.13 link: dwarf: missing type: type.uintptr results in SIGSEGV when linking go code
to:
Go rpm package spec define NO_BRP_STRIP_DEBUG=true NO_BRP_AR=true to avoid sort.a(__.PKGDEF) sort.a(_go_.o): Unable to recognise the format of file: file format not recognized


The original message is only a symptom of the underlying problem. The rpm .spec packaging of go1.13 as well as other versions except for go1.11 and go1.12 do not uniformly have both __arch_install_post defines necessary to prevent the build service from automatically stripping Go .a archives. 

That commented section which should appear in all versions of Go is as follows:

# strip will cause Go's .a archives to become invalid because strip appears to
# reassemble the archive incorrectly. This is a known issue upstream
# (https://github.com/golang/go/issues/17890), but we have to deal with it in
# the meantime.
%undefine _build_create_debug
%define __arch_install_post export NO_BRP_STRIP_DEBUG=true NO_BRP_AR=true

Without these controls, go builds will generate objcopy errors like the following:

objcopy:(...)/go/1.13/pkg/linux_amd64/sort.a(__.PKGDEF): Unable to recognise the format of file: file format not recognized
objcopy:(...)/go/1.13/pkg/linux_amd64/sort.a(_go_.o): Unable to recognise the format of file: file format not recognized

Importantly, this behaviour does *not* cause the build to fail, even thought the binaries are rendered partially unusable as shown by the original symptom reported in this issue.

It would be helpful to apply checks to ensure the symptom has not cropped up again in the future by failing the builds where stripping of Go .a archives occurs and is reported as an error by objcopy and other tools.

The following listing is a partial listing of the go versions in devel:languages:go where the term strip appears. As of this writing only go1.11 and go1.12 have both defines.
All versions should be updated with both defines to ensure stripping of .a archive binaries is fully suppressed.

devel:languages:go> grep -i strip go1.*/*.spec
go1.7/go1.7.spec:# strip will cause Go's .a archives to become invalid because strip appears to
go1.7/go1.7.spec:%define __arch_install_post export NO_BRP_STRIP_DEBUG=true
go1.8/go1.8.spec:# strip will cause Go's .a archives to become invalid because strip appears to
go1.8/go1.8.spec:%define __arch_install_post export NO_BRP_STRIP_DEBUG=true
go1.9/go1.9.spec:# strip will cause Go's .a archives to become invalid because strip appears to
go1.9/go1.9.spec:%define __arch_install_post export NO_BRP_STRIP_DEBUG=true
go1.10/go1.10.spec:# strip will cause Go's .a archives to become invalid because strip appears to
go1.10/go1.10.spec:%define __arch_install_post export NO_BRP_STRIP_DEBUG=true
go1.11/go1.11.spec:# strip will cause Go's .a archives to become invalid because strip appears to
go1.11/go1.11.spec:%define __arch_install_post export NO_BRP_STRIP_DEBUG=true NO_BRP_AR=true
go1.12/go1.12.spec:# strip will cause Go's .a archives to become invalid because strip appears to
go1.12/go1.12.spec:%define __arch_install_post export NO_BRP_STRIP_DEBUG=true NO_BRP_AR=true
go1.13/go1.13.spec:# strip will cause Go's .a archives to become invalid because strip appears to
go1.13/go1.13.spec:%define __arch_install_post export NO_BRP_STRIP_DEBUG=true

Additionally versions go1.4 and go1.6 should be updated with the same defines and comment.
go1.4 is of particular importance as it is the recommended bootstrap version by way of being the last version of Go implemented as a C program. go1.4 has long term support by upstream as the bootstrap version.

This issue can be closed when all versions of Go in devel:languages:go have both defines.
First Last Prev Next    This bug is not in your last search results.