This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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.