bug with PI mutex and static linking

[Carlos O'Donell]

On Fri, Feb 12, 2016 at 2:27 AM, Warlich, Christof
<christof.warlich@siemens.com> wrote:
> Carlos wrote:
>
>> $GCC -r -nostdlib -o libpthread.o -Wl,--whole-archive ./libpthread.a
>> rm libpthread.a
>> ar rcs libpthread.a libpthread.o
>
> Again, thanks a lot for this: It perfectly fixed the problem!

Glad to hear it, that's why we have libc-help :-)

> Looks like static builds do more and more become second class citizens only:
> I assume that static builds are not covered during GLIBC regression testing?

It is true that for a while the community actually considered removing
static linking altogether.

However, over the past 5 years the consensus has changed that we need
to support it to some degree and document the caveats that exist.

Static linking *is absolutely* covered by glibc regression testing,
but this particular case is not tested because it would always fail
e.g. XFAIL (expected fail).

Static linking is exceedingly complex to get right because of the
semantics of the linkage model, and it causes some interesting
side-effects that most inexperienced users don't understand.

Static linking effectively creates an alternate namespace, which when
coupled with dlopen causes two namespaces to exist within a single
static application. These two namespaces have no coordination today
and can cause serious problems if you are not careful.

It is discussed in some detail here (version two of the C and C++
packaging guidelines for Fedora, not yet official):
https://fedoraproject.org/wiki/C_and_C++_v2#Static_Linking

> Lesson learned on our side: If we seriously want to continue to support static
> builds, we have to run the GLIBC test suite for static builds ourselves.

Not so.

A better lesson might be: work with upstream on enabling better
support for the features that are of interest to you? ;-)

Cheers,
Carlos.