Actually gozk does use cgo. Check here <https://searchcode.com/codesearch/view/44309507/>.
gozk is a wrapper on top of c client which is a wrapper on top of java code. Not if we check the symbols present in c client of zookeeper, we'll see : 204: 000000000001313f 132 FUNC LOCAL DEFAULT 1 copy_table 205: 00000000000131c3 106 FUNC LOCAL DEFAULT 1 collect_session_watchers 206: 000000000001322d 95 FUNC LOCAL DEFAULT 1 add_for_event 207: 000000000001328c 144 FUNC LOCAL DEFAULT 1 do_foreach_watcher 208: 0000000000000000 0 FILE LOCAL DEFAULT ABS hashtable.c * 209: 0000000000013560 25 FUNC LOCAL DEFAULT 1 indexFor* 210: 0000000000001cc0 104 OBJECT LOCAL DEFAULT 4 primes 211: 000000000001374f 780 FUNC LOCAL DEFAULT 1 hashtable_expand 212: 0000000000000000 0 FILE LOCAL DEFAULT ABS hashtable_itr.c * 213: 0000000000013e46 25 FUNC LOCAL DEFAULT 1 indexFor* 214: 0000000000001d2c 4 OBJECT GLOBAL DEFAULT 4 max_load_factor 215: 0000000000011393 506 FUNC GLOBAL DEFAULT 1 adaptor_init 216: 0000000000004a4a 27 FUNC GLOBAL DEFAULT 1 deallocate_SetACLResponse Looking at the code this is a static inline function which is used by two translation units. Defined in hastable_private <https://github.com/krux/zookeeper-pkg/blob/master/src/c/src/hashtable/hashtable_private.h>.h as a static inline method. Used in two translation units : 1) HASHTABLE_SRC = src/hashtable/hashtable_itr.h src/hashtable/hashtable_itr.c \ src/hashtable/hashtable_private.h src/hashtable/hashtable.h src/hashtable/hashtable.c 2) COMMON_SRC = src/zookeeper.c include/zookeeper.h include/zookeeper_version.h include/zookeeper_log.h\ src/recordio.c include/recordio.h include/proto.h \ src/zk_adaptor.h generated/zookeeper.jute.c \ src/zookeeper_log.h src/zk_log.c src/zk_hashtable.h src/zk_hashtable.c as seen in Makefile.am. <http://makefile.am./> Now I think c/c++ linker allows multiple definitions of the same symbol but go linker disallows it. As a result of which while compiling go code which uses gozk I ran into following warnings : 2016/08/23 11:24:25 symbol go.dwarf.info.indexFor listed multiple times. My linker flags were :ld_flags = '-linkmode=internal -r "%s/lib" -I "%s" -X \'ts/common.buildinfo=%s\'' % ( GetToolChainSysroot(), GetToolchainLoader(), base64.b64encode(GetBuildInfo())) To get around this issue I removed --linkmode=internal which got rid of the compile time warnings and gave me the compiled binaries. But the binaries segfaulted with stack trace listed above. Why do we not support duplication symbols in go <https://golang.org/src/cmd/link/internal/ld/objfile.go>? On Monday, August 22, 2016 at 12:20:38 PM UTC-7, Prateek Gaur wrote: > > In order to use one <https://github.com/emicklei/go-restful> of the go > packages I updates my golang version from 1.5.2 to 1.7. > > But after update my go binaries seem to be segfaulting with following > output : > [1] 19583 segmentation fault (core dumped) ./go/bin/<binary name> > > The core file gives following bt: > > #0 _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:56 > #1 0x0000000000934624 in get_xid () > #2 0x000000000093708d in __libc_csu_init () > #3 0x00007fb238dc571f in __libc_start_main () from > path/crosstool/v4/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sysroot/lib/libc.so.6 > #4 0x0000000000407f59 in _start () > > Do we know what could be causing this problem? > > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
