Perhaps you're running into https://github.com/golang/go/issues/13492.
- elias On Friday, April 12, 2019 at 5:06:08 AM UTC+2, Chao Chen wrote: > > I don't understand initial exec TLS model. But I meet the following > problem when use go shared library. *When I load Go shared library from > python2.7 script on alpine 3.9 container.**Would you please give some > suggestions? I am so appreciated for your help!* > *When I call Go shared library from python2.7 script on alpine 3.9 > container.*failed with OSError: Error relocating ./cc.so: : initial-exec > TLS resolves to dynamic definition in ./cc.so > <https://stackoverflow.com/questions/55642942/python-on-alpine-ctypes-loadlibrary-failed-with-oserror-error-relocating-cc> > > > /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 > - show quoted text - > Code: > //main.go package main import "C" //export add func add(left, right int) > int { return left + right } //export minus func minus(left, right int) int > { return left - right } //export multiply func multiply(left, right int) > int { return left * right } //export divide func divide(left, right int) > int { return left / right } //export testPrint func testPrint(){ > print("test") } func main() { } // test.py import ctypes lib = > ctypes.cdll.LoadLibrary('./cc.so') if lib is not None: print ("can load so") > > On Thursday, May 30, 2013 at 4:16:35 AM UTC+8, Elias Naur wrote: >> >> Hi, >> >> A few months ago, I got some CLs reviewed and submied that added some low >> level work towards support for creating shared libraries written in Go. The >> more intrusive runtime changes were never accepted, so I'd like to propose >> a more clean, simple, and hopefully more acceptable way of supporting >> shared library in the Go runtime and tools. This proposal uses linux >> terminology, but shared libraries on the other OSes are (hopefully) similar. >> >> *Go shared libraries* >> Supplying the -shared flag to 6l will output a shared library that is >> similar to a go program, but with a few notable differences: >> >> Just as a go program includes all the referenced go code and the go >> runtime, a go shared library is a dynamic shared object (.so file) that >> includes all the referenced go code and the runtime. >> >> When a go program is executed, the main thread calls into the Go runtime, >> which is initialized, init functions are run and finally, main() is run. A >> go library does not own the native program's main thread, and in fact might >> not even be loaded from the main thread (in the dlopen() case). >> Instead, the thread loading the go library spawns a new thread which from >> then on functions as the Go main thread. The fresh go main thread in turn >> runs go runtime initialization and then notifies the loading thread to >> return control to the main program. The runtime initialization for go >> libraries is the same as for ordinary go programs, except that main() is >> expected to return, and that go won't exit the program when that happens. >> I don't have strong feelings about running main() or not, but running it >> is the closest to normal go program behaviour, and then main() can double >> as a "library init" function. >> After initialization, the main program can call into the Go library just >> as if a foreign thread called into Go in a Cgo program. >> >> Deadlock detection is effectively disabled in go libraries, even if no >> cgo calls have been made from Go, because it can't be known whether the >> main program is deadlocked or not. >> >> os.Args normally contain the programs arguments. Shared libraries >> generally don't have access to the program arguments without cooperation >> from the main program, so os.Args length is 0 for go libraries. >> >> *Linux/amd64 implementation* >> To test the proposal and to make sure it is complete, I've added support >> for go shared libraries to the linux/amd64 platform. It builds on the >> existing -shared flag, and on the recent support for external linking and >> callbacks from foreign threads. >> >> The low level and less intrusive changes are in >> https://codereview.appspot.com/9733044/. It reimplements -shared in 6l >> with external linking and adds support for the initial exec TLS model. This >> CL contains what I believe is the necessary linker changes for go shared >> library support, regardless of how the runtime changes and user visible >> semantics end up to be. If my runtime proposal is not accepted, it is my >> hope that this CL can be reviewed on any technical problems and submitted >> anyway. >> >> The runtime changes are in https://codereview.appspot.com/9738047/. It >> contain the meat of the proposal and I expect this CL to contain the most >> controversy, if any. The CL also includes a test for a basic C program >> linking to a go library and a more advanced C program that dlopen()s a go >> library and use __thread TLS variables. >> >> The implementation has some limits that are not inherent in the proposal: >> >> >> - Shared library support is not "out of the box", in the sense that >> Go (on amd64) must be built with the -largemodel flag to gc and cc to >> support go libraries. Ordinary go programs can still be built with those >> flags, but the position independent code and the initial exec TLS model >> makes the resulting executables slightly slower. This restriction is >> similar to the race detector, which also needs a special build to >> function. >> Ideally, the same Go build should support both ordinary go programs and >> go >> libraries without any unnecessary speed penalty. Advice on how to >> implement >> that in the tooling is welcomed. >> - 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. >> - No go tool flag ("-shared"?) has been added yet, but can be >> trivially added. >> >> >> *Linux/arm * >> The 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. >> >> - elias >> > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
