This is the mail archive of the libc-alpha@sources.redhat.com 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: GCC 3.4 and glibc/nptl: Cancellation broken


Hi,

On Fri, 23 Jan 2004, Jakub Jelinek wrote:

> Usually binaries don't export their symbol tables, so this wouldn't change
> much.

Hmm, right.  That Unwind_SetGR from the executable was used is only 
because libgcc_s isn't linked into the test programs (so the reference 
from personality was statically resolved).  Sorry for confusion.

> *libgcc:
> %{static|static-libgcc:-lgcc -lgcc_eh} \
> %{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --start-only-if-used -lgcc_s%M --end-only-if-used} \
> 			   %{shared-libgcc:-lgcc_s%M %{!shared:-lgcc}}}}
> 
> That way, -static or -static-libgcc will link in libgcc.a and libgcc_eh.a,
> but nothing else.  The program/shared library will have DT_NEEDED
> libgcc_s.so.1 if linked with -shared-libgcc or if some symbol from
> libgcc_s.so.1 minus libgcc.a was needed by the executable or shared library
> (e.g. if it used -fexceptions and __attribute__((cleanup)) ).

I see.  Especially no non-static programs would link against libgcc_eh.a.

I guess in a static executable (i.e. linked against libgcc_eh) glibc will
not dlopen libgcc_s.so ?  Because otherwise we would have the same
situation as currently.


Ciao,
Michael.


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