-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
-lpthread revert broke gccgo on ppc64le (at least) #203
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
Comments
@minux is it possible to avoid this with something like |
libgo itself requires pthread, so i don't understand how could you link a
Go program without -lpthread implied.
How to produce this? This might be a problem of the go tool bundled
with gccgo.
/cc @ianlancetaylor
|
We're running into that issue using gccgo 5.0 on ppc64le (and I suspect on other arches too but I don't have access to arm64 right now to confirm) |
OK, the gccgo go tool should add -pthread to the final linking command,
to match the behavior the gc (where the runtime/cgo package will add
-lpthread as needed.)
|
So it may well be that gccgo is the problem, unfortunately changing the compiler isn't something I can trivially do, and retro-actively doing so for existing older releases is even less likely to happen. Can anyone think of a problem with using:
That should be specific enough not to affect anyone else. |
How does this problem arise? As minux said, libgo is already linked against libpthread. When linking statically, the gccgo driver adds an explicit -lpthread. So what precisely are you doing to cause a problem? And what precisely happens? |
Still not sure exactly what's going on as I can't reproduce the issue with a simple example but can when attempting to build our project (and its ton of dependencies). Anyway, looks like adding -lpthread to our own cgo file fixes things so I'll just do that. |
The -lpthread option is required for pthread trylock under gccgo at least for ppc64le (likely more architectures too).
If setting it for everyone breaks some cases, can we at least keep it for gccgo+linux?
The text was updated successfully, but these errors were encountered: