[CentOS-devel] __gthrw___pthread_key_create in devtoolset-6

Fri Jun 1 06:57:58 UTC 2018
dacav <dacav at teknik.io>

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