Skip to content
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

runtime/cgo: _cgo_sys_thread_start error: implicit declaration of function #12029

Closed
frederich opened this issue Aug 5, 2015 · 4 comments
Closed

Comments

@frederich
Copy link
Contributor

Windows amd64 build of go1.5beta3 fails.

v% all.bat
...
cmd/pack
# runtime/cgo
runtime\cgo\gcc_windows_amd64.c: In function '_cgo_sys_thread_start':
runtime\cgo\gcc_windows_amd64.c:32:2: error: implicit declaration of function '_beginthread' [-Werror=implicit-function-declaration]
  thandle = _beginthread(threadentry, 0, ts);
  ^
cc1: all warnings being treated as errors
cmd/pprof/internal/profile
cmd/pprof/internal/tempfile
...

v% gcc --version
gcc (GCC) 4.9.2
@ianlancetaylor ianlancetaylor added this to the Go1.5 milestone Aug 5, 2015
@ianlancetaylor
Copy link
Contributor

Any idea why _beginthread is not declared in <process.h>? Is your GCC a cygwin or mingw32 build?

CC @alexbrainman

@ianlancetaylor
Copy link
Contributor

Also, the line "cc1: all warnings being treated as errors" implies that something is passing -Werror to GCC. Any idea where that is coming from? As far as I can tell the Go build process does not add it.

@frederich
Copy link
Contributor Author

Hi Ian,

I use the MSYS2 installer (https://msys2.github.io) which is a popular lightweight 64-bit POSIX environment. Bazel use it too (http://bazel.io/docs/windows.html).

I think it's a mingw-w64 gcc.

@rsc
Copy link
Contributor

rsc commented Aug 5, 2015

Hi. Windows ports of gcc vary wildly. As documented on https://github.com/golang/go/wiki/InstallFromSource#install-c-tools, building Go from source requires TDM-GCC. My understanding is that MSYS2 is the same kind of thing as Cygwin. I'm glad that works for Bazel, but Go expects to use the raw Windows libraries, not a POSIX wrapper. I don't believe we are going to support Go using POSIX wrapper utilities. Doing both is too hard, and the POSIX wrappers always eventually get in the way.

@rsc rsc closed this as completed Aug 5, 2015
@golang golang locked and limited conversation to collaborators Aug 5, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants