Comment 1:

Status changed to LongTerm.

Comment 2 by eugueny:

Ughh... Shared libraries are target #1 for any lower-level systems programming language.
Most code on my system is in .so files and nearly all my code runs under either nginx or
python processes, I just don't see how I can use Go.

Comment 4 by geek@duzy.info:

expecting SO

Comment 5:

Labels changed: added priority-later.

Comment 7:

will issue #4069 help with this?

Comment 8:

Yes, except that issue #4069 doesn't mention to generate PIC object files
which is preferable (but not essential) for shared objects.
If issue #4069 is solved, at least we can generate non-PIC .so.

Comment 9:

There's been some progress recently:
http://code.google.com/p/go/source/detail?r=885321ad387328c16c6f69fb04b12ac69b69b691
http://code.google.com/p/go/source/detail?r=c9e8491bbfcee7a9c05934f8be0718bccbf29aec
http://code.google.com/p/go/source/detail?r=98034d036d03213807879975629172945169c7c8
http://code.google.com/p/go/source/detail?r=1eadf11dd1b7b19d4857681363553c2cfd2ad47d

Comment 11 by geek@duzy.info:

-shared is not available in 6l, 8l, 5l etc

Comment 12 by geek@duzy.info:

-shared is now available in 6l, 8l, 5l etc

Comment 13:

-shared is not enumerated in go help build.

Comment 14:

Labels changed: added go1.3maybe.

Comment 15 by rasmus@mindplay.dk:

The changes you are working on - will they provide .so only or .dll on Windows too?
I am fast falling in love with Go, but realized too late that although it is technically
a "system" programming language, things like shell-extensions and plug-ins are still out
of reach...

Comment 16:

I'm only working on Linux support, but if that is accepted and added to mainline in some
form, Windows support will be a relatively minor change.

Comment 17:

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

Comment 18:

Labels changed: added repo-main.

Comment 19:

following https://code.google.com/p/go-wiki/wiki/HandlingIssues
here is a quick rationale:
- allow some form of dynamic code loading
- ability to, say, implement a CPython module in Go (or a ruby one, or...)

Comment 20 by peter@scraperwiki.com:

I would also like to be able to implement an NSS module using go, which is not possible
without this functionality.

Comment 21 by bkcsfi:

I would like to build PPAPI plugins in Go.. Need DLL generation support for that.

Comment 22 by rasmus@mindplay.dk:

Writing a VST plugin in this language would be so bad ass, since Go provides performance
suitable for real-time DSP.

Comment 23:

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

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

This issue is a little vague. It now works in some ways on some systems on tip, using -buildmode=shared, -buildmode=c-shared, and -linkshared.

Let's move more specific uses on specific systems to separate issues.

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

Reflection also needs to be considered when loading a library; I may not know what symbols are available; but I know what interfaces I support, so being able to scan a dynamically loaded extension for its types and picking those with interfaces of interest is useful.

I started today thinking about writing plugins for an existing shell I have. This would have been first 'can Go link shared libraries?' But on further consideration, if it did use shared libraries how would I use them?
c# doesn't really behave like dlopen/dlsym/et al It instead gives back lists of types that can be queries for support. An alternative available on C# is Attributes; but go has no idea about attributes so it would definitly have to be done with reflection