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.

[1]: https://stackoverflow.com/questions/15599714/risks-of-different-gcc-versions...

/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),

I forgot to post some follow-up to this story, since I was able to solve it. I'm reporting my findings here, just in case someone else is experimenting the same kind of problem.

Tl;Dr: macros in headers probably contain some bug.

First off, I noticed that this particular symbol is supposed to be a "weak symbol" in the ELF object file, aliasing the internal __pthread_key_create call.

A weak symbol should never trigger a linking problem: in the worst case no regular symbol is supplied, hence the weak definition is used at link time. The linking problem is a clear indication of an error of some kind.

Then I found out that the same definition is included in every single file of the project I was compiling, but only one file was actually obtaining a missing symbol definition.

After a good session of trial-and-error, together with a colleague of mine we figured out that a well placed `#include <thread>` in the beginning of the culprit file was automagically solving everything. By placing that `#include` before anything else, we are probably toggling some `#define` which is preventing the weird situation from happening. Go and figure out what macro gets changed! :)

Interestingly, no thread whatsoever is declared in that file. As a matter of facts, the same software, inclusive of the culprit file, was compiling just fine under different systems.

My suspect is that the whole thing is due to some error in the preprocessor definitions of the involved headers, which screwed up the definition of the weak symbol, and change it into an expected regular symbol.

It must kept in mind that we are talking about compiling C++14 on a somewhat old operating system by means of a backported compiler, so I guess it's a quite peculiar situation.

Cheers, and sorry for the wall-of-text :)