Re: [PATCH] Fix linking C executables/shared libraries which use__attribute__((cleanup ()))

[Richard Sandiford <rsandifo at redhat dot com>]

Jakub Jelinek <jakub@redhat.com> writes:
> Hi!
>
> Alan recently implemented support for conditional linking of shared
> libraries.  The follwoing patch is the GCC side of the needed changes.
> Without it for example gcc 3.4+ compiled NPTL C programs using
> pthread_cleanup_{push,pop} will not handle cancellation properly.
> This patch just changes the default behaviour, when neither -static-libgcc
> nor -shared-libgcc is specified.  The program or shared library will be
> linked against libgcc_s if EH is used and just against libgcc.a if not.
> Ok to commit?
> For 3.4/3.3 as well (bootstrapped/regtested in 3.4 on x86_64-redhat-linux
> so far)?
>
> 2004-03-27  Alan Modra  <amodra@bigpond.net.au>
> 	    Jakub Jelinek  <jakub@redhat.com>
>
> 	* gcc.c (init_gcc_specs): If HAVE_LD_AS_NEEDED, link with
> 	-lgcc --as-needed -lgcc_s --no-as-needed by default.
> 	* configure.ac (HAVE_LD_AS_NEEDED): Check for ld --as-needed.
> 	* configure: Rebuilt.
> 	* config.in: Rebuilt.

This patch causes some bootstrap problems for mips-sgi-irix6.5 if using
a prebuilt 2.15 binutils.  I hesitate to say it's "broken" bootstrap,
but every program built by the stage1 compiler now depends on libgcc_s.so,
so it's necessary to set up LD_LIBRARY*_PATHs for the gcc build directory
before starting the build.  I gather that this isn't necessary for
*-linux-gnu targets.

As far as I can tell, libgcc_s is always treated as needed, since it
resolves undefined weak symbols in crtbegin.o (__register_frame_info,
__deregister_frame_info and _Jv_RegisterClasses).  Every C program,
even "int main () { return 0; }", will therefore require libgcc_s.so.

I haven't really been following the discussion, or the --as-needed
option, so is this the intended effect?

As you can probably tell, this message is something of a rush job.
I'd like to have spent more time looking into the history of the
options before posting.  However, since it's a 3.4 issue, I thought
I'd better send something as soon as possible.

Oh, and sorry for not noticing earlier.  Although the patch has been in
3.4 for a couple of weeks now, I've previously been testing with a combined
tree.  The version check for a combined tree looks for binutils >= 2.16,
which isn't satisfied by CVS mainline, and so --as-needed support was
always disabled.  I only tripped over the problem when testing a separate
build from binutils 2.15 branch.

Anyway, would it be worth converting the autoconf test to use AC_CACHE_CHECK,
as per the patch below?  At least it would give users a way of overriding
the test without having to patch configure.ac.

I've verified that the check still passes on i686-pc-linux-gnu after
this patch.  Testing mips-sgi-irix6.5 bootstraps overnight.

Richard


Index: configure.ac
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.ac,v
retrieving revision 2.6.2.12
diff -u -p -F^\([(a-zA-Z0-9_]\|#define\) -r2.6.2.12 configure.ac
--- configure.ac	1 Apr 2004 16:47:54 -0000	2.6.2.12
+++ configure.ac	14 Apr 2004 20:22:12 -0000
@@ -2627,8 +2627,9 @@ if test x"$gcc_cv_ld_pie" = xyes; then
 fi
 AC_MSG_RESULT($gcc_cv_ld_pie)
 
-AC_MSG_CHECKING(linker --as-needed support)
-gcc_cv_ld_as_needed=no
+AC_CACHE_CHECK(linker --as-needed support,
+gcc_cv_ld_as_needed,
+[gcc_cv_ld_as_needed=no
 if test $in_tree_ld = yes ; then
   if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 16 -o "$gcc_cv_gld_major_version" -gt 2 \
      && test $in_tree_ld_is_elf = yes; then
@@ -2640,11 +2641,11 @@ elif test x$gcc_cv_ld != x; then
 		gcc_cv_ld_as_needed=yes
 	fi
 fi
+])
 if test x"$gcc_cv_ld_as_needed" = xyes; then
 	AC_DEFINE(HAVE_LD_AS_NEEDED, 1,
 [Define if your linker supports --as-needed and --no-as-needed options.])
 fi
-AC_MSG_RESULT($gcc_cv_ld_as_needed)
 
 if test x$with_sysroot = x && test x$host = x$target \
    && test "$prefix" != "/usr" && test "x$prefix" != "x$local_prefix" ; then