Jack Howarth <howa...@bromo.med.uc.edu> writes: > Actually that wasn't the fix. The change...
> void > -__go_scanstacks (void (*scan) (byte *, int64_t)) > +__go_scanstacks (void (*scan) (unsigned char *, int64)) Thanks. Sorry for misunderstanding. I committed the change from int64_t to int64. > /var/tmp//ccVFZHcc.s:3:Expected comma after segment-name > /var/tmp//ccVFZHcc.s:3:Rest of line ignored. 1st junk character valued 32 ( ). > /var/tmp//ccVFZHcc.s:3:Junk character 92 (\). > /var/tmp//ccVFZHcc.s:3:Rest of line ignored. 1st junk character valued 49 (1). This is the problem I mentioned earlier about generating the .go_export section. I think the fix here is either going to be to use a magic string in the call to get_section in gcc/go/gofrontend/export.cc or some additional support in darwin_asm_named_section in config/darwin.c. > ../../../gccgo/libgo/go/runtime/error.go:20:19: error: use of undefined type > 'Type' > ../../../gccgo/libgo/go/runtime/error.go:20:19: error: use of undefined type > 'Type' > ../../../gccgo/libgo/go/runtime/error.go:20:19: error: use of undefined type > 'Type' > ../../../gccgo/libgo/go/runtime/error.go:20:19: error: use of undefined type > 'Type' > go1: internal compiler error: in do_get_tree, at > go/gofrontend/expressions.cc:1177 > Please submit a full bug report, > with preprocessed source if appropriate. > See <http://gcc.gnu.org/bugs.html> for instructions. > ../../../gccgo/libgo/go/runtime/extern.go:181:23: error: reference to > undefined name 'theGoarch' > ../../../gccgo/libgo/go/runtime/extern.go:163:9: error: reference to > undefined name 'defaultGoroot' > ../../../gccgo/libgo/go/runtime/extern.go:172:9: error: reference to > undefined name 'theVersion' > ../../../gccgo/libgo/go/runtime/extern.go:177:21: error: reference to > undefined name 'theGoos' Something is wrong in that error.go and extern.go are being compiled separately rather than together. I think this means that the gcc driver has set combine_inputs to false for some reason. Ah, this happens if no explicit -o option was used. The question then is why libtool did not use an explicit -o option. The answer to that may be buried in your config.log, or it may be some odd libtool choice. Actually it should not really depend on -o anyhow, gccgo should force it somehow. Thanks for looking into this. Ian
