Am 22.05.2018 um 15:04 schrieb dacav dacav@teknik.io:
On 2018-05-22, dacav dacav@teknik.io wrote:
Then of course it gets problematic upon linking time
objs/intel-debug/src/logd-main.o:(.rodata+0x8): undefined reference to `__gthrw___pthread_key_create(unsigned int*, void (*)(void*))' collect2: error: ld returned 1 exit status
With a colleague we did some further investigation… and I had some additional understanding.
I could verify that the missing symbol is generated by an header file which belongs to the compiler:
/opt/rh/devtoolset-6/root/usr/include/c++/6.3.1/x86_64-redhat-linux/bits/gthr-default.h:236:10: warning: 'int __gthrw___pthread_key_create(pthread_key_t*, void (*)(void*)) throw ()' used but never defined BUILDSTDERR: __gthrw2(__gthrw_(__pthread_key_create),
The current CentOS libc, and specifically libpthread.so, does not provide such symbol: it is not reported in `objdump --syms`.
For what I understand, devtoolset is providing static linkage for the functionalities which are not available in the "regular" CentOS libc. That's the role of libstdc++_nonshared.a according to [this stackoverflow post][1]. So I also went for `objdump --syms /opt/rh/devtoolset-6/.../libstd++_nonshared.a`. I found nothing.
So, in short it would seem like I'm not linking against some important object code. This object file might be in the standard CentOS, but more likely in some devtoolset package. The weird part is that `-pthread` should be (in my opinion) take care of all this for me.
At this point I'm somewhat out of bullets :) If someone has some suggestion I will appreciate it. And of course I apologize for the spam.
There exist a backward [1] but not a forward compatibility. IMHO your executable must be build statically. In that sense everything needed is provided by your executable.
[1] https://mirrors.edge.kernel.org/pub/software/libs/glibc/hjl/compat/
-- LF