LRN <lrn1986@xxxxxxxxx> writes: > On Tue, Jun 14, 2011 at 1:24 AM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: >> LRN <lrn1986@xxxxxxxxx> writes: >> >>> However, if i put anything more complex than "return 1" into Myfunc in >>> Go (such as using fmt.Printf() or returning a string - with >>> appropriate prototype changes to 'string' and 'char*' in Go and C, >>> naturally), it segfaults at runtime. >>> >>> Is that a limitation of gccgo, a bug, or am i simply doing something wrong? >> >> This is a current limitation of gccgo. At present nothing initializes >> the packages imported by a packaged compiled into a shared library. >> This is fixable with a bit of thought but is not high on the priority >> list. > How's it going? Any news. The status is unchanged. > As a side note, after discussing [1] static linking in Go (due to the > fact that go doesn't have dynamic linking), i thought a bit, and came > up with this: > > ---------main_shared.go > package main_shared > > import ( > "fmt" > ) > > func Myfunc () string { > return "result" > } > > type ComplexType struct { > somestring string > someint int > } > > func Myfunc2 (n int) (r ComplexType) { > r.somestring = fmt.Sprintf ("a formatted version of integer %d", n) > r.someint = n > return > } > ---------end of main_shared.go > > ---------main_executable.go > package main > > import ( > "fmt" > ) > > func myfunc () string __asm__ ("go.main_shared.Myfunc") > > type ComplexType struct { > somestring string > someint int > } > > func myfunc2 (n int) (r ComplexType) __asm__ ("go.main_shared.Myfunc2") > > func main() { > s := myfunc () > fmt.Printf ("Calling myfunc() resulted in a string %s\n", s) > n := 5 > c := myfunc2 (n) > fmt.Printf ("Passing %d to myfunc2() resulted in %s (with an integer > %d)\n", n, c.somestring, c.someint) > } > ---------end of main_executable.go > > compile and run: > gccgo -g -O0 -fPIC -shared main_shared.go -o libmain_shared.so -lgcc > gccgo -g -O0 main_executable.go -o main -L. -lmain_shared > LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./main > > and it prints: > Calling myfunc() resulted in a string result > Passing 5 to myfunc2() resulted in a formatted version of integer 5 > (with an integer 5) > > Which was expected. > > ldd says that the executable is linked to libgo and libmain_shared: > > $ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ldd ./main > linux-vdso.so.1 => (0x00007fff9022b000) > libmain_shared.so => ./libmain_shared.so (0x00007f0e4a7fa000) > libgo.so.0 => /usr/lib/x86_64-linux-gnu/libgo.so.0 (0x00007f0e49bb7000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0e49934000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0e4971e000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0e4939a000) > /lib64/ld-linux-x86-64.so.2 (0x00007f0e4a9ff000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0e4917d000) > > I thought that since the problem lies in libgo not being initializing, > then it should work with the main executable written in Go, because it > does initialize its own runtime library, which is then shared with > libmain_shared. > > My guess is that this will only work when both modules are linked to > the same version of libgo. Yes, it should work in that case, I think. I have not actually tried it, though. > Is it ever going to be a valid way of linking Go modules, or just a hack? There will probably be a way to dynamically link Go modules at some point, but I don't know when. Ian