x/tools/go/analysis: golang-x-tools doesn't build with gccgo (testsuite failures) #29990
Trying to build golang-x-tools with gccgo from gcc-8 fails due to multiple testsuite failures:
To reproduce on Debian unstable:
The text was updated successfully, but these errors were encountered:
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.
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.
@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?