Am 22.05.2018 um 15:04 schrieb dacav <dacav at teknik.io>: > > On 2018-05-22, dacav <dacav at 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