--
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/d/optout.
On Fri, Jul 17, 2015 at 9:47 AM, Hiroaki Nakamura <hnak...@gmail.com> wrote:
>
> * dlclose now runs successfully without segmentation fault.
I would not count on dlclose working.
> How can I know the go initialization thread finishes from C?
Currently you can't. Calling a Go function waits for the
initialization thread to complete, but there is no way to wait without
calling a Go function. Please open an issue for this. Thanks.
On Fri, Jul 17, 2015 at 4:55 PM, Hiroaki Nakamura <hnak...@gmail.com> wrote:
> 2015-07-18 7:49 GMT+09:00 Ian Lance Taylor <ia...@golang.org>:
>>
>> On Fri, Jul 17, 2015 at 9:47 AM, Hiroaki Nakamura <hnak...@gmail.com>
>> wrote:
>> >
>> > * dlclose now runs successfully without segmentation fault.
>>
>> I would not count on dlclose working.
>
> Could you tell me why, please?
> I thought dlclose is working because "after dlclose" is printed
> with code at
> https://github.com/hnakamur/export_c_variable_from_go_dll_experiment/blob/1951dfb411dcff8986687ca98f801505397fc6cf/runtime_load.c#L18
The Go runtime starts threads on which it runs goroutines. If any of
those threads are running when you call dlclose, your program is
likely to crash. Currently there is no way to cleanly shut down the
Go runtime.
> Now what to do about these two problems?
>
> * compile time link example on Linux
> * i remains 0
This is the problem we have been talking about, isn't it?
> * on osx
> * link error: ld: 1 duplicate symbol for architecture x86_64
I don't know. Is there an issue for this one?
On Fri, Jul 17, 2015 at 9:09 PM, Hiroaki Nakamura <hnak...@gmail.com> wrote:
>
> No, it is a different problem.
>
> https://github.com/hnakamur/export_c_variable_from_go_dll_experiment/blob/master/compiletime_load.c
>
> ```
> #include <stdio.h>
> #include <dlfcn.h>
> #include "libgodll.h"
>
> int main(int argc, char **argv) {
> printf("compiletime_load started\n");
> usleep(1000 * 1000);
> printf("i=%d\n", i);
> return 0;
> }
> ```
>
> The code above prints `i=0` instead of `i=1`.
Yes. You need to call a Go function in order for initialization
functions to run. Calling sleep is not reliable.
>> > * on osx
>> > * link error: ld: 1 duplicate symbol for architecture x86_64
It may be that GCC and clang have different defaults for whether "int
i;" is a common symbol. It may be necessary to use something like
#cgo CFLAGS "-fcommon"
assuming that works with clang.