| Message ID | mcra9re8d64.fsf@google.com |
|---|---|
| State | New |
| Headers | show |
Ian Lance Taylor <iant@google.com> writes: > 2013-02-08 Ian Lance Taylor <iant@google.com> > > * lib/go.exp: Load timeout.exp. ERROR: Couldn't find library file timeout.exp. Andreas.
On Sat, Feb 9, 2013 at 3:18 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: > Ian Lance Taylor <iant@google.com> writes: > >> 2013-02-08 Ian Lance Taylor <iant@google.com> >> >> * lib/go.exp: Load timeout.exp. > > ERROR: Couldn't find library file timeout.exp. Sorry, I was told on IRC that the patch worked. As I mentioned on the bug, can you figure out why it fails? The file gcc/testsuite/lib/go.exp does a load_lib of several files from that directory. Why would they all work but loading timeout.exp fails? Ian
Am 09.02.2013 19:24, schrieb Ian Lance Taylor: > On Sat, Feb 9, 2013 at 3:18 AM, Andreas Schwab <schwab@linux-m68k.org> wrote: >> Ian Lance Taylor <iant@google.com> writes: >> >>> 2013-02-08 Ian Lance Taylor <iant@google.com> >>> >>> * lib/go.exp: Load timeout.exp. >> >> ERROR: Couldn't find library file timeout.exp. > > Sorry, I was told on IRC that the patch worked. yes, it did work for me, but I only tested the default multilib location. > As I mentioned on the bug, can you figure out why it fails? The file > gcc/testsuite/lib/go.exp does a load_lib of several files from that > directory. Why would they all work but loading timeout.exp fails? but as I see now, it seems to fail for the non-default multilib locations. Is there a somewhere a missing .. in a path? the libgo testsuite unfortunately works not as all other testsuite for the libraries do work. Usually if you do want to test a multilib build, you call RUNTESTFLAGS="--target_board=unix\{,-m32,-mx32\}" make -k check and only the check target for the default multilib is called. libgo however descends into the non-default multilib targets and calls check there too. And then with the above RUNTESTFLAGS, every go test is called nine times instead of three times, and apparently fails the other six times. Please let libgo behave the same as the other target libraries for the check target, even it does introduce some delta. Maybe this is seen on m68k too, because it's a multilib configuration too? Matthias
On Mon, Feb 18, 2013 at 12:23 AM, Matthias Klose <doko@ubuntu.com> wrote: > >> As I mentioned on the bug, can you figure out why it fails? The file >> gcc/testsuite/lib/go.exp does a load_lib of several files from that >> directory. Why would they all work but loading timeout.exp fails? > > but as I see now, it seems to fail for the non-default multilib locations. Is > there a somewhere a missing .. in a path? I thought this was fixed now by a patch to libgo/testsuite/lib/libgo.exp. Are you still seeing trouble with current mainline? > the libgo testsuite unfortunately works not as all other testsuite for the > libraries do work. Usually if you do want to test a multilib build, you call > > RUNTESTFLAGS="--target_board=unix\{,-m32,-mx32\}" make -k check > > and only the check target for the default multilib is called. libgo however > descends into the non-default multilib targets and calls check there too. And > then with the above RUNTESTFLAGS, every go test is called nine times instead of > three times, and apparently fails the other six times. > > Please let libgo behave the same as the other target libraries for the check > target, even it does introduce some delta. I can't remember if there is a bug report open for this or not. Ian
Am 18.02.2013 20:07, schrieb Ian Lance Taylor: >> the libgo testsuite unfortunately works not as all other testsuite for the >> > libraries do work. Usually if you do want to test a multilib build, you call >> > >> > RUNTESTFLAGS="--target_board=unix\{,-m32,-mx32\}" make -k check >> > >> > and only the check target for the default multilib is called. libgo however >> > descends into the non-default multilib targets and calls check there too. And >> > then with the above RUNTESTFLAGS, every go test is called nine times instead of >> > three times, and apparently fails the other six times. >> > >> > Please let libgo behave the same as the other target libraries for the check >> > target, even it does introduce some delta. > I can't remember if there is a bug report open for this or not. this is now PR go/56432.
Index: lib/go.exp =================================================================== --- lib/go.exp (revision 195909) +++ lib/go.exp (working copy) @@ -19,6 +19,7 @@ # load_lib prune.exp load_lib gcc-defs.exp +load_lib timeout.exp load_lib target-libpath.exp #