-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/link: OS X codesign only works with -ldflags -s #11887
Comments
Please run "go build -ldflags=-v" and attach the output. I'd like to confirm that the linker is invoking the external linker. Thanks. |
|
Thanks. We apparently have a program built by clang for which codesign does not work. Off hand I have no guess as to what the Go linker might be doing to cause this to fail. This will have to be tackled by somebody who understands how codesign works on Darwin. |
If you build with |
Thanks, that does seem to work. |
For more information see: golang/go#11887
Any thoughts on whether we should document this for Go 1.5, and where we should do it? Ideally we should put the docs in the place where someone who encounters the problem will look, but where would that be? |
Passing the '-s' flag to the linker in < Go 1.5 emits an error and produces a binary that, once codesigned (I believe) will cause an immediate bus error and terminate.
|
Issue still exists on 1.6,
Probably going to forgo codesigning for now, but eager to learn about another workaround or a real fix! 🌟 |
The |
That would be really hard to do accidentally, one would have to run: go build -ldflags "-extldflags -s" instead of: go build -ldflags "-s" and I can assure you I was doing the latter. However, I suspect cmd/link is passing |
If the problem with cmd/link is just dwarf, then try -ldflags -w instead of On Tue, Mar 22, 2016 at 12:00 PM Amos Wenger notifications@github.com
|
With |
I'm finding that
|
Following the exact same protocol, but with my program, I'm able to reproduce your results on my local MacbookPro, but not on my build server.
The build server has an older version of clang & OSX:
My local computer has the latest stable of both:
Note that, even on my local machine, $ go build -v -x -ldflags "-s -v" -o butler-s .
# (manually suppressed output for readability)
# note the "-s" below
host link: "clang++" "-m64" "-s" "-Wl,-no_pie,-headerpad,1144" "-Wl,-pagezero_size,4000000" "-o" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-build649125102/github.com/itchio/butler/_obj/exe/a.out" "-Qunused-arguments" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-link-896862525/go.o" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-link-896862525/000000.o" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-link-896862525/000001.o" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-link-896862525/000002.o" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-link-896862525/000003.o" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-link-896862525/000004.o" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-link-896862525/000005.o" "/var/folders/kj/vbzcvcf94hn0hkxpc6d97zcc0000gn/T/go-link-896862525/000006.o" "-g" "-O2" "-g" "-O2" "-g" "-O2" "-lpthread" "-g" "-O2" "-framework" "CoreFoundation" "-framework" "Security" "-g" "-O2" "-g" "-O2" "-g" "-O2"
# here's the warning
ld: warning: option -s is obsolete and being ignored I'd understand if this bug doesn't receive a lot of attention, since recent clangs seem to handle it just fine. I'll just upgrade my build server, thanks for the help! 🌟 edit: if anyone's interested in reproducing the above, the program I'm building is https://github.com/itchio/butler edit 2: note that the simple 11887.go test case posted by @gazed above isn't enough to reproduce the problem |
I'm currently running into this exact issue without performing any explicit code signing. I updated my mac yesterday with the latest command line tools and Xcode, version 8.3, and I believe exactly then is when I started seeing this issue. I'm on macOS version The failure happens even when doing a vanilla Here's a file causing failures when I package main
import (
"unsafe"
)
/*
#include <stdio.h>
#include <stdlib.h>
void myprint(char* s) {
printf("%s\n", s);
}
*/
import "C"
func main() {
cs := C.CString("Hello from stdio\n")
C.myprint(cs)
C.free(unsafe.Pointer(cs))
} My theory is that something in the update to the command line tools is causing a breakage here. |
It looks like the new issues are now being tracked here: #19734 |
CL https://golang.org/cl/38853 mentions this issue. |
I see now what happened with -s above: passing -s to the Go linker relays it to the macOS linker. And even though the macOS linker says it is ignoring -s, it seems to not be ignoring it quite enough. This was #19775 just now. I expect the fix for that will be in Go 1.8.1, so that you can use -ldflags=-s successfully on binaries with external linking. I hope that will get codesign working again. In fact codesign might start working out of the box without any special flags. At least on my machine right now:
I don't know if using Thanks. |
Might as well provide a way around the mach-o munging that doesn't require stripping all symbols. After all, -w does mean no DWARF. For #11887, #19734, and anyone else that needs to disable this code path without losing the symbol table. Change-Id: I254b7539f97fb9211fa90f446264b383e7f3980f Reviewed-on: https://go-review.googlesource.com/38853 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL https://golang.org/cl/39602 mentions this issue. |
… (in addition to -s) Might as well provide a way around the mach-o munging that doesn't require stripping all symbols. After all, -w does mean no DWARF. For #11887, #19734, and anyone else that needs to disable this code path without losing the symbol table. Change-Id: I254b7539f97fb9211fa90f446264b383e7f3980f Reviewed-on: https://go-review.googlesource.com/39602 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Might as well provide a way around the mach-o munging that doesn't require stripping all symbols. After all, -w does mean no DWARF. For golang#11887, golang#19734, and anyone else that needs to disable this code path without losing the symbol table. Change-Id: I254b7539f97fb9211fa90f446264b383e7f3980f Reviewed-on: https://go-review.googlesource.com/38853 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
use go1.8.1 fixed it good |
Using the Go 1.5 compiler toolchain and compiling a binary that uses CGO and then
codesign
ing that binary, upon attempting to execute the program it will be killed immediately by the system. Codesigning a non-cgo binary works just fine, as expected.Given the following small program:
and building simply with
go build
and runningcodesign -f -s my_cert ./myprog
, when attempting to execute the program in a shell the response is "killed: ./myprog".The system log reports:
Tested against Go1.5beta2 and:
The text was updated successfully, but these errors were encountered: