Linux/armThe basic -shared flag support is already present on linux/arm, and I plan to implement this updated proposal for linux/arm too. However, since external linking is now required, I'd like to know if anyone (Russ?) is already working on that? If not, I'd like to go ahead and attempt an implementation of external linking myself.
On Wed, May 29, 2013 at 1:16 PM, Elias Naur <elias...@gmail.com> wrote:
>
> Multiple go libraries loaded in the same native program, or a go program
> loading a go library probably won't work. An immediate showstopper is that
> cgo currently exports some symbols (x_cgo_init etc.) in all go libraries and
> programs. Multiple go libraries are also inefficient, in the sense that they
> won't share a single runtime, heap, garbage collector, etc.
This is an interesting approach, but I think it is clear that we need
to understand multiple Go shared libraries without just failing
horribly. Should each shared library live in its own world? That
will not play well with dlopen. Should all the shared libraries live
in the same world? That raises questions about initialization.
Also, if we support dlopen, what should we do for dlclose? E.g., what
if you dlopen a shared library, it calls runtime.SetFinalizer, and
then you dlclose that library?
I think this is good work, but I also think we need to figure out
these questions, at least to the extent that we know where we are
heading even if it doesn't yet work.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I apologize if this question was already answered somewhere else, but...
I'm puzzled as to why you propose putting the runtime in each go shared library. Typically when you have a shared dependency, that code is placed in a separate shared library. On linux at least it's also possible to leave the runtime in the executable if the executable is linked with -rdynamic/--export-dynamic (at least according to the dlopen man page). I'm not aware of a way to do this on Windows so the runtime would have to be in a separate DLL.
Having the runtime in a separate shared library makes it possible to load multiple go shared libraries in the same executable.
So, I guess the question is, was this options considered and discarded and if so, why?
All the problems from last year remain: why should the init only happen once but
the main start anew on each call?
Why is it reasonable for os.Args to be empty?
What about the environment? And so on.
And so on.
This CL will then contain only the new design decisions about this "library"
mode. This is the part I am fundamentally unsure about. There are complications
having to do with what happens when the m0 exits, how you handle multiple
threads calling into Go simultaneously, why there is no os.Args, whether signal
handlers should persist on return, whether other M's that are started during the
call should be killed at return, and so on. But at least if we get the other
mechanical details done we can have that conversation.
Go the spec says nothing about libraries. I just don't expect to see such support in the gc implementation. But other implementations? Why not? As long as it doesn't somehow violate the spec, right? Maybe gccgo is a more likely candidate
One Go core team member's opinion on shared libraries: http://harmful.cat-v.org/software/dynamic-linking/Go the spec says nothing about libraries. I just don't expect to see such support in the gc implementation. But other implementations? Why not? As long as it doesn't somehow violate the spec, right? Maybe gccgo is a more likely candidate
--To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/zmjXkGrEx6Q/unsubscribe.
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
/usr/src/app # go build -o cc.so -buildmode=c-shared main.go
/usr/src/app # readelf -d cc.so
Dynamic section at offset 0x10cd10 contains 22 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.musl-x86_64.so.1]
0x0000000000000010 (SYMBOLIC) 0x0
0x000000000000000c (INIT) 0x42000
0x000000000000000d (FINI) 0x92ed9
0x0000000000000019 (INIT_ARRAY) 0xa2078
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x270
0x0000000000000005 (STRTAB) 0xa50
0x0000000000000006 (SYMTAB) 0x378
0x000000000000000a (STRSZ) 1026 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x10deb0
0x0000000000000002 (PLTRELSZ) 720 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x41a00
0x0000000000000007 (RELA) 0xe58
0x0000000000000008 (RELASZ) 265128 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000000000001e (FLAGS) SYMBOLIC BIND_NOW STATIC_TLS
0x000000006ffffffb (FLAGS_1) Flags: NOW NODELETE
0x000000006ffffff9 (RELACOUNT) 11040
0x0000000000000000 (NULL) 0x0
/usr/src/app # python test.py
Traceback (most recent call last):
File "test.py", line 2, in
lib = ctypes.cdll.LoadLibrary('./cc.so')
File "/usr/lib/python2.7/ctypes/init.py", line 444, in LoadLibrary
return self._dlltype(name)
File "/usr/lib/python2.7/ctypes/init.py", line 366, in init
self._handle = _dlopen(self._name, mode)
OSError: Error relocating ./cc.so: : initial-exec TLS resolves to dynamic definition in ./cc.so