-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
x/tools/go/analysis: golang-x-tools doesn't build with gccgo (testsuite failures) #29990
Comments
It's a hard problem to solve. gccgo doesn't provide the source code for its standard library. go/packages seems to assume source code access and doesn't seem to fall back on the importer. So analyses that depend on looking at standard library packages won't work with go/packages. I'm not sure how to move forward. |
CC @ianthehat |
Yes, many of our tools assume accurate source is available all the way down. One solution would be for gccgo to install source for its standard library. My habit is to make dozens of trips into the source for the standard and other libraries every day to understand the behavior of programs I build. If I was using gccgo as my main compiler, the first thing I'd do would be to install source for its std lib. Perhaps other users of gccgo might appreciate it too. |
@alandonovan Debian does have a source code package installable for the standard Go compiler (gc). If you tell me where the sources have to be located, I can probably modify the golang-x-tools Debian package to build-depend on this source package. |
@glaubitz The gccgo sources are not the same as the gc sources, though. @alandonovan That's quite different from how GCC works in general, though. GCC does not install the sources for the C++ library on your local machine. Of course they are readily available for those who want to look at them. But most installations of GCC are on containers and servers where nobody will ever want to look at source code. |
I think there are two separate concerns here. It can be asked to work in pure source mode, and many tools do that (including the new language service provider). I don't see any way to change this, there are lots of things that just don't work or make sense without the source. Whether we just say those tools don't work in gcc mode or we try to fix it is a different problem to the one being reported in this bug. |
Coincidentally, I was investigating build failures on Debian for x/tools. Honestly, I don't know the details of all this, so I would appreciate if somebody tells me if there is a workaround for this (making sources available somehow?), or if I should just disable these tests on gccgo? |
@TheTincho I don't think there is a workaround at present, though we should work on one. |
Trying to build golang-x-tools with gccgo from gcc-8 fails due to multiple testsuite failures:
build log
To reproduce on Debian unstable:
<\details>
Installing
golang-go
instead ofgccgo-go
fixes the testsuite, so it's an issue related to gccgo.CC @jrtc27 @ianlancetaylor
The text was updated successfully, but these errors were encountered: