Re: gccgo branch and darwin

[Ian Lance Taylor <iant at google dot com>]

Jack Howarth <howarth@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