This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran"


TL;DR: See last...

> From: Ulrich Weigand <uweigand@de.ibm.com>
> Date: Tue, 25 Aug 2015 14:59:05 +0200

> However, the compiler actually does accept -fPIC.  If the flag is
> present, we attempt to generate relocatable code, but only to the
> extent the compiler can do that without support for run-time
> relocations.  The most significant restriction is that statically
> initializing a global variable to a pointer will not work.
> (This is useful for some special cases of self-relocating code.
> Such code normally can work around this restriction.)

Still, things like that is why I chose to emit a hard error for
-fPIC/-fpic where it's not supported for *all* code...


> Now, with the patch above, libbacktrace is still compiled with
> -fPIC on SPU, but some files do in fact contain just such global
> initializers, causing compilation to fail:
> 
> gcc-head/src/libbacktrace/elf.c:241:27: error: creating run-time relocation for '*.LC2'
>  static const char * const debug_section_names[DEBUG_MAX] =
>                            ^
> The other GCC run-time libraries rely on libtool to figure out
> that even though -fPIC works, dynamic libraries are still not
> supported on the platform, and thus compile everything for
> static linking (i.e. without -fPIC).

That's not what I see, at least not the "figuring out" part.
(They mostly use libtool as-is; some test tuples, but some test
version-script support and add it then.)

> I'm wondering if we couldn't use the same libtool mechanism here:
> if the architecture does not support dynamic linking at all, no
> target library will be built as shared library, and thus there is
> no need to build libbacktrace with -fPIC either.  (My understanding
> is that we need to build libbacktrace with -fPIC because it might
> get linked into some other shared target library.)

Yes, that's what the comment in the patch context says, as
happens for libgfortran.

> The libbacktrace configure script actually incorporates all the
> libtool init code that makes this determination, and sets the
> shell variable "can_build_shared" to "no" on SPU.  Would it be
> valid to use this variable in the test whether to use -fPIC?
> (I'm not sure which of the many libtool variables are intended
> to be used outside, and which are private ...)

I momentarily pondered this too, when I found the libtool
PIC-test-code grepping libtool/configure, but I chose the
simpler TRY_COMPILE test partly for the same
maybe-internal-variable reason.  A visit to the libtool
documentation shows can_build_shared is for some reason not
listed among the documented variables and a STFW doesn't yield
more information for the first few pages of hits (just some
indexed random libtool copies).  On the other hand, libtool.m4
is in the top directory, so we know if we switch to some version
without can_build_shared.

I'll leave that to you to sort out, but if you chose to use
$can_build_shared, consider also setting PIC_FLAG to $pic_flag
(instead of plain -fPIC).  In the meantime I'll commit my patch
as it solves *some* of the breakage; for targets erroring on -fPIC.

...but reading the libtool documention I think I found a much
better solution: Let's just add -prefer-pic when compiling
libbacktrace.  It leaves everything to libtool.  Can you please
test this?

libbacktrace:
	* configure.ac: Use libtool option -prefer-pic, not -fPIC.
	* configure: Regenerate.

diff -upr /expvol/pp_slask/hp/checkout/gcchead/gcc/libbacktrace/configure.ac libbacktrace/configure.ac
--- libbacktrace/configure.ac	2015-05-29 17:23:20.000000000 +0200
+++ libbacktrace/configure.ac	2015-08-24 17:31:18.000000000 +0200
@@ -163,10 +163,11 @@ fi

 # When building as a target library, shared libraries may want to link
 # this in.  We don't want to provide another shared library to
-# complicate dependencies.  Instead, we just compile with -fPIC.
+# complicate dependencies.  Instead, we prefer PIC, if the target
+# supports that through libtool.
 PIC_FLAG=
 if test -n "${with_target_subdir}"; then
-  PIC_FLAG=-fPIC
+  PIC_FLAG=-prefer-pic
 fi
 # Similarly, use -fPIC with --enable-host-shared:
 AC_ARG_ENABLE(host-shared,

brgds, H-P


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