This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: bug with PI mutex and static linking
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Warlich, Christof" <christof dot warlich at siemens dot com>
- Cc: "Sudler, Simon" <simon dot sudler at siemens dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>, "Hartmann, Wolfgang" <wolfgang dot hartmann at siemens dot com>
- Date: Fri, 12 Feb 2016 10:21:25 -0500
- Subject: Re: bug with PI mutex and static linking
- Authentication-results: sourceware.org; auth=none
- References: <6D83E89737156549AEA25EF9ED712C5D18EDE2 at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <CAE2sS1gnYZDc0uwx+W2xY+f7SH=i1cFF7o==EUyF9SNXWWqHzA at mail dot gmail dot com> <6D83E89737156549AEA25EF9ED712C5D18EF29 at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <CAE2sS1hz=woxZCb43+TtPHK=V_qOkTSqM3r+VO1Ua4EOEqzcAQ at mail dot gmail dot com> <6D83E89737156549AEA25EF9ED712C5D18F001 at DEFTHW99EK1MSX dot ww902 dot siemens dot net>
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.