[Bug go/89171] FAIL: go/build

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171

Andreas Schwab  changed:

   What|Removed |Added

 Target|riscv64-*-* |

--- Comment #5 from Andreas Schwab  ---
If $GOROOT is unset, ctxt.GOROOT it set to "/usr".  listStdPkgs then finds all
the files in /usr/src/debug.

[Bug go/89171] FAIL: go/build

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171

--- Comment #4 from Ian Lance Taylor  ---
To run, say, just the go/build test, cd to the libgo build directory and run
"make go/build/check".  To keep the test binary around, run "make
GOTESTFLAGS=--keep go/build/check".  That will leave the test binary (and other
stuff) in the directory gotestN/test.  In that directory you can run
"LD_LIBRARY_PATH=../../.libs ./a.out -test.short".  That executable also takes
other options, like "-test.run=TestDependencies" to run just the
TestDependencies test.

[Bug go/89171] FAIL: go/build

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171

--- Comment #3 from Andreas Schwab  ---
How can I build and run a single libgo test?

[Bug go/89171] FAIL: go/build

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171

--- Comment #2 from Andreas Schwab  ---
There are prebuilt images in
 that are set up
to execute via qemu linux-user emulation.

[Bug go/89171] FAIL: go/build

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171

--- Comment #1 from Ian Lance Taylor  ---
I don't know what is happening here and I don't have access to a riscv64
machine to test on (there doesn't seem to be one in the compile farm).  The
errors are incorrect in that these are not expected dependencies, not
unexpected ones.  This may be a bug in the generation of top level composite
literals, though I can't think of any reason that would be specific to riscv64,
and of course it is working on other systems.

Do you have any suggestions for how I could debug this?