This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Memory fencing problem in pthread cancellation
On Tue, Jan 15, 2013 at 04:32:37PM +0000, Joseph S. Myers wrote:
> On Tue, 15 Jan 2013, Carlos O'Donell wrote:
>
> > There might previously have been a bootstrapping issue in requiring
> > a libgcc_s.so to link against because you can't have built all of
> > the dynamic pieces of gcc?
>
> Indeed, if you want to put libgcc_s.so.1 (or another SONAME on a few
> architectures) in DT_NEEDED, you need to do so in a way that does not
> involve any previously installed libgcc_s.so.1 (e.g., glibc could build
> its own dummy library and use that at static link time, as long as it
> doesn't get used later when running tests), so that building glibc with a
> static-only compiler continues to work and produce the same results as
> building it with a compiler with shared libgcc.
On modern gcc, libgcc_s.so.1 is not even needed; support for
dl_iterate_phdr makes it so linking libgcc_eh.a into multiple DSOs
works fine even if unwinding crosses DSO boundaries. Thus, removing
the dynamic loading of libgcc_s.so.1 and just directly referencing the
unwind symbols should give the correct behavior regardless of which
sort of libgcc is being used. Personally, I would suggest building
libpthread.so with -static-libgcc so that the unwind support just gets
builting rather than loading an extra .so at program load time or at
runtime. This is by far the cleanest solution.
Rich