Comment 1:

Labels changed: added priority-later, removed priority-triage.

Status changed to LongTerm.

Comment 2 by lewis@squareup.com:

I am interested in this as well.  I'd like to use Go to make PostgreSQL extensions among
other things.  It provides a unique balance between simplicity of scripting languages
and performance of a compiled language.
To me, go seems like it's ideal for implementing database features.

Comment 4 by Szczur.nh:

I am interested in this as well. I want to use Go as script language in my app.

Comment 5:

Elias Naur is working on this: https://golang.org/cl/6822078

Comment 6:

Updated implementation (and linux/amd64 implementation) at
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/zmjXkGrEx6Q

Comment 7:

Labels changed: added go1.3maybe.

Comment 8 by jwatte@imvu.com:

Go might be able to do something here. LUA is too simplistic, and the syntax is wonky.
V8 is too heavy-weight, and single-threaded. Python is single-threaded. A good embedding
interface could have significant value!

Comment 9:

Labels changed: added release-none, removed go1.3maybe.

Comment 10:

Labels changed: added repo-main.

Comment 11:

CL https://golang.org/cl/9738047 references this issue.

I just wrote a blog post about this:

Using Go in mobile apps, Part 1: Calling Go functions from C++

Seems like #256 is related and #4848 is a duplicate

See https://docs.google.com/a/golang.org/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit#heading=h.fwmrrio0df0i

@ianlancetaylor Thanks for posting the document. It appears that adding -buildmode=archive would be the simplest of all these, right? And this would allow linking from C code and manually starting the Go runtime? I'm considering trying to implement this sometime soon. Is it on the official Go roadmap at all?

Thanks for your interest. You should coordinate with Michael Hudson-Doyle michael.hudson@canonical.com. He is the only person I know to be working in this area at the moment.

Does anyone know if there has been any progress on any of these ideas?

I'm specifically interested in what's described in the doc @ianlancetaylor mentioned as Go code linked into, and called from, a non-Go program.

I have a large(ish) C++ app and I'd like to reimplement part of it in Go as a static lib and just link it in using my current build process.

Michael Hudson-Doyle has been working on shared libraries.

I plan to work on linking Go into a C program soon but I haven't started yet.

Yes, I'm making progress on shared libraries, and also understanding how awkward doing dlopen-style embedding is going to be :-)

It doesn't feel like embedding Go as a static library should be all that hard? cgo_static_export the right things, avoid generating a entrypoint, generate a .o as for host linking and then don't invoke the host linker?

Oh, I guess you have to worry about TLS a bit.

Thank you @ianlancetaylor - I look forward to it! If you need some help testing when you get to that point please let me know.

@asmaloney I had an idea about how to do this, though I haven't tried it out yet.

1. Compile Go code into an executable normally with go build
2. Run obcopy to rename main() to startGoRuntime()
3. Rename the executable to myGoLib.o
4. Link your C program against that .o file
5. Call startGoRuntime() from your C code (in a new thread) whenever you need to start the Go runtime (can only do this once obviously)

This method has limitations – for example, I'm pretty sure C code could never call into Go code from a non-Go thread.

Isn't this already implemented using the -buildmode flag? As far as I know it generates a header and a .a file, which should satisfy this issue.

Yes, this should now work on tip, using -buildmode=c-archive or -buildmode=c-shared. They don't work on all systems, but let's use separate issues to track specific systems where they need work.

Are there plans to support freebsd (if someone doesn't feel like using the linux compatability layer and 32-bit binaries)?

@eatonphil We try not to hold discussions on closed issues. See https://golang.org/wiki/Questions .

I would be happy to review patches adding support for FreeBSD. It shouldn't be hard. As I said above, you can also open a separate issue for that.

Sorry about that! I misread the "Open" sign above my comment as referring to this thread.

I'll open a new issue.