Build hangs after "cd ../test"

[Mr. Wobbet]

Running 32-bit Snow Leopard on MacBook Pro 2,2.

Retrieved from Mercurial and had errors related to not having the GO*
env vars in sudoers. Once that was "resolved" (I think that's a
bug...) the code appears to build and then start running through
tests. But it never finishes. Instead it will just sit at "--- cd ../
test" for hours without doing anything other than making the fan spin.

I haven't run any language tests as of yet (later today!) but feel
confident that everything is built and I can start coding. But I'm a
bit put off that the build doesn't finish.

Many thanks!

rjsjr

--- cd cmd/gofmt
rm -f *.[568vq] gofmt
8g -o _go_.8 gofmt.go
8l -o gofmt _go_.8

real 0m0.345s
user 0m0.280s
sys 0m0.058s
./test.sh /Users/wobbet/go/src/pkg/go/parser/parser.go

PASSED (2 tests)

real 0m0.927s
user 0m0.877s
sys 0m0.043s

--- cd cmd/ebnflint
rm -f *.[568vq] ebnflint
8g -o _go_.8 ebnflint.go
8l -o ebnflint _go_.8

real 0m0.228s
user 0m0.181s
sys 0m0.043s
ebnflint -start="SourceFile" /Users/wobbet/go/doc/go_spec.html

real 0m0.034s
user 0m0.024s
sys 0m0.007s

--- cd ../misc/cgo/stdio
rm -rf *.[568vqo] *.a [568vq].out *.cgo[12].go *.cgo[34].c *.so _obj
_test _testmain.go hello fib chain run.out
cgo file.go
8g -o _go_.8 file.cgo1.go file.cgo2.go
8c -FVw -I/Users/wobbet/go/src/pkg/runtime file.cgo3.c
rm -f _obj/stdio.a
gopack grc _obj/stdio.a _go_.8 file.cgo3.8
cp _obj/stdio.a /Users/wobbet/go/pkg/darwin_386/stdio.a
gcc -m32 -fPIC -O2 -o file.cgo4.o -c file.cgo4.c
gcc -m32 -o stdio_file.so file.cgo4.o -dynamiclib -Wl,-
undefined,dynamic_lookup
cp stdio_file.so /Users/wobbet/go/pkg/darwin_386/./stdio_file.so
8g hello.go
8l -o hello hello.8
8g fib.go
8l -o fib fib.8
8g chain.go
8l -o chain chain.8
rm stdio_file.so file.cgo4.o
rm -rf *.[568vqo] *.a [568vq].out *.cgo[12].go *.cgo[34].c *.so _obj
_test _testmain.go hello fib chain run.out

--- cd pkg/exp/ogle
rm -rf *.[568vqo] *.a [568vq].out *.cgo[12].go *.cgo[34].c *.so _obj
_test _testmain.go ogle
8g -o _go_.8 abort.go arch.go cmd.go event.go frame.go goroutine.go
rruntime.go rtype.go rvalue.go process.go vars.go
rm -f _obj/exp/ogle.a
gopack grc _obj/exp/ogle.a _go_.8
8g -I_obj main.go
8l -L_obj -o ogle main.8

real 0m1.159s
user 0m0.919s
sys 0m0.181s

--- cd ../doc/progs

real 0m3.062s
user 0m1.936s
sys 0m0.488s

--- cd ../test/bench
fasta
reverse-complement
nbody
binary-tree
binary-tree-freelist
fannkuch
regex-dna
spectral-norm
k-nucleotide
mandelbrot
meteor-contest
pidigits
threadring
chameneosredux

--- cd ../test

[Mr. Wobbet]

Got a message saying this was fixed and I needed to "hg pull -u" so I
did. Now I get...

%%%% making cmd/cgo %%%%

8g -o _go_.8 ast.go gcc.go main.go out.go util.go
8l -o cgo _go_.8
exec·Run: undefined: runtime·arraytoslice
hash_remove_n: undefined: mmov
make: *** [cgo] Error 1

What's that?

rjsjr

[Ian Lance Taylor]

"Mr. Wobbet" <wob...@gmail.com> writes:

> Got a message saying this was fixed and I needed to "hg pull -u" so I
> did. Now I get...
>
> %%%% making cmd/cgo %%%%
>
> 8g -o _go_.8 ast.go gcc.go main.go out.go util.go
> 8l -o cgo _go_.8
> exec·Run: undefined: runtime·arraytoslice
> hash_remove_n: undefined: mmov
> make: *** [cgo] Error 1
>
> What's that?

This appears to be a dependency bug, although I'm not sure what causes
it. Running all.bash a second time seems to avoid the problem and
succeed.

Ian

[Juztin]

I too had the build hang during the tests. I was building with arch
386 on a mac mini w/Snow Leopard.
I checked out the latest last night (11-22-09)
I then built again using arch amd64 and no hang during the tests..
Before I built the 64 bit version though I simply just control c'd the
test and all was well.

[Russ Cox]

On Mon, Nov 23, 2009 at 09:12, Juztin <jus...@redyetis.com> wrote:
> I too had the build hang during the tests. I was building with arch
> 386 on a mac mini w/Snow Leopard.
> I checked out the latest last night (11-22-09)
> I then built again using arch amd64 and no hang during the tests..

Right. When you check out a new tree with clone -r release,
you get the most recent release, which contains this bug on
386 Snow Leopard. If you run "hg pull -u" you switch from
running the release to the bleeding edge code (sometimes
broken in other ways), which does address this bug.

As you say, it's okay to just ctrl-c the test and move on too.

Russ