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"


Ian Lance Taylor wrote:
> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> 
> > 	* configure.ac: Only compile with -fPIC if the target
> > 	supports it.
> > 	* configure: Regenerate.
> 
> This is OK.

I'm now running into the same problem on SPU, but unfortnately
this patch still doesn't fix the problem.

Now, the SPU does not support dynamic loading and the loader
does not support (most) run-time relocations.  There is no
support for shared libraries on the SPU.  On the SPU, all
GCC target libraries are built as static libraries, and
should be compiled without -fPIC.

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.)

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).

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.)

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 ...)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com


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