This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 to link against because you can't have built all of
> > the dynamic pieces of gcc?
> Indeed, if you want to put (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 (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, 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 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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]