Re: [boost] Static initialization of boost shared objects question

Subject: Re: [boost] Static initialization of boost shared objects question
From: Juan Carlos Franzoy (jfranzoy_at_[hidden])
Date: 2013-01-26 12:54:37

> Posts stand a better chance of being read by the right person if they
> include the library name  in square brackets at the beginning of the
> subject line. For example, "[regex]" or "[filesystem]". The subject

I agree, thanks. But in this specific case I do not know if it is
specific to a library.
I thought it could be off-topic, that it could be a compiler or linker issue.
Then, as I was unsure, I decided to post it anyway.

I found the "presumed problem" because of an error: I was linking to
ALL boost libraries.

When I corrected to link only with Boost.System and Boost.Filesystem
and the problem
didn't happen.

> Are you saying that a data race occurs during static initialization,
> and that causes a deadlock?

I do not see a data race at all in c++ code.

My "thesis" is that gcc/ld/ld.so may introduce reentrancy in any
function called at static
initialization time if this function refer to a symbol defined in
another shared library.
This occurs because the load of other shared library starts the static
initialization of that
shared library.

If you add the fact that inline functions or compiler generated
members are instantiated
as weak symbols in all shared libraries that uses them, you end up
with a lot of candidates
of unintentional calls from one shared library to another. Please
refer to the original post.

This would disable calling inline function of compiler generated
members from non-reentrant
functions called at static initialization.

Note: I want to know if this reasoning is correct.

> Does this always occur with programs that use Boost System, or only
> when combined with Wave?

Only linking to a lot of the libraries.

> Have you tried to construct a simple test program that illustrates the problem?

Yes I did, but I did not succed.