Re: Using Go to build a shared library to be called from C

[LRN <lrn1986 at gmail dot com>]

On 14.06.2011 1:24, Ian Lance Taylor wrote:
> LRN<lrn1986@gmail.com>  writes:
>
> > However, if i put anything more complex than "return 1" into Myfunc in
> > Go (such as using fmt.Printf() or returning a string - with
> > appropriate prototype changes to 'string' and 'char*' in Go and C,
> > naturally), it segfaults at runtime.
> >
> > Is that a limitation of gccgo, a bug, or am i simply doing something wrong?
> This is a current limitation of gccgo.  At present nothing initializes
> the packages imported by a packaged compiled into a shared library.
> This is fixable with a bit of thought but is not high on the priority
> list.
While i certainly in no position tell the others what is high-priority 
and what isn't, i feel that i should point out that the ability to 
combine shared libraries written in Go with non-go programs would allow 
any software to leverage Go's abilities (mostly - its easy-to-use 
concurrency model, even if its implementation in gccgo is not efficient 
at the moment) by re-implementing some parts in Go, while keeping 
everything else in C (or whatever is being used).

Anyway, if this situation is not going to change for some time, it might 
be a good thing to update the documentation to make it clear what works 
and what doesn't.

Ah, and another thing. Does that apply to static linking as well? I 
suddenly realized that if it does, then why the hell the documentation 
even mentions C->Go interoperability?