*Do you any progress to solve the problem? I meet the same problem.*
w
<https://stackoverflow.com/questions/55642942/python-on-alpine-ctypes-loadlibrary-failed-with-oserror-error-relocating-cc>hen
I call golang build shared library on python from 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
On Wednesday, May 25, 2016 at 7:14:02 AM UTC+8, Justin Israel wrote:
>
> I've got one more question, related to this process, now that this library
> is seeing some production use...
>
> The C++ Go binding shared library is being used as a dependency in another
> library. This other library is a plugin that gets loaded via dlopen. I am
> seeing the following:
>
> dlopen: cannot load any more object with static TLS
>
> In doing some research, I found that this happens when shared libs default
> or use "-ftls-model=initial-exec" and/or don't use "-fpic". So it a
> situation of the big pool of plugins that get dlopen'd into this particular
> application, and the static TLS slots running out when enough of them use
> initial-exec.
>
> I was looking at my shared lib that is created via "go build
> -buildmode=c-shared -gcflags=-shared -asmflags=-shared
> -installsuffix=_shared -a" and I do see it using "-fPIC". After doing some
> SO research, someone suggested doing the following to determine the TLS
> mode that is being used:
>
>
> http://stackoverflow.com/questions/22983986/is-there-a-way-to-determine-thread-local-storage-model-used-by-a-library-on-linu
>
> $ readelf -d libgofileseq.so | grep FLAGS
> ... (FLAGS) SYMBOLIC STATIC_TLS
>
> It seems no combination of trying to add "-ftls-model=global-dynamic" to
> my compile process can resolve the problem. Are there any suggestions of
> where this change can be applied, to correct the situation where dlopen
> fails? We have found that if this plugin using this shared library gets
> loaded first, then we don't encounter the static TLS failure.
>
> Justin
>
>
>
> On Wednesday, May 18, 2016 at 3:11:57 PM UTC+12, Justin Israel wrote:
>>
>> I'm wondering if someone can tell me if this is either a limitation of
>> buildmode=c-archive static libs, or if I am really just doing something
>> wrong.
>>
>> Problematic steps:
>>
>> 1. export functions to libgofoo.a using buildmode=c-archive
>> 2. statically link libgofoo.a into another library to produce libfoo.a
>> 3. Someone else consumes libfoo.a and libgofoo.a in their library,
>> and get linker errors about:
>> ld: libgofoo.a(go.o): relocation R_X86_64_TPOFF32 against
>> `runtime.tlsg` can not be used when making a shared object; recompile
>> with
>> -fPIC
>> libgofoo.a: could not read symbols: Bad value
>>
>> But library that wants to consume these libs can do so if they
>> dynamically link with shared libs from c-shared. Also, if the consumer
>> of the libs is a main binary, then the static linking works and does not
>> complain. It is only when the target is a library.
>>
>> I could swear I went through and ensured -fPIC was being used, but it
>> didn't seem to make a difference. Am I infact just messing up my
>> compilation settings and failing to add this flag as it suggests, or is
>> there a known limitation related to the steps I have outlined?
>>
>> Thanks!
>> Justin
>>
>>
--
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.
