Re: [PATCH] Fix and simplify (Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran)
Ian Lance Taylor wrote: Ulrich Weigand uweig...@de.ibm.com writes: I've verified that this works on x86_64: the resulting libgfortran.so uses the -fPIC version of the libbacktrace object, while libgfortran.a uses the non-PIC versions. On SPU, libtool will now automatically only generate the non-PIC versions since the target does not support shared library. So everything works as expected. OK for mainline? Can you verify that libgo works as expected? Looks correct to me: On x86_64, libgo.so contains -fPIC versions of the backtrace routine, while libgo.a contains non-PIC versions. (There's no Go support on SPU.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: [PATCH] Fix and simplify (Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran)
Ulrich Weigand uweig...@de.ibm.com writes: Ian Lance Taylor wrote: Ulrich Weigand uweig...@de.ibm.com writes: I've verified that this works on x86_64: the resulting libgfortran.so uses the -fPIC version of the libbacktrace object, while libgfortran.a uses the non-PIC versions. On SPU, libtool will now automatically only generate the non-PIC versions since the target does not support shared library. So everything works as expected. OK for mainline? Can you verify that libgo works as expected? Looks correct to me: On x86_64, libgo.so contains -fPIC versions of the backtrace routine, while libgo.a contains non-PIC versions. (There's no Go support on SPU.) Your patch to libbacktrace is OK. Thanks. Ian
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
From: Ulrich Weigand uweig...@de.ibm.com Date: Wed, 26 Aug 2015 13:45:35 +0200 Hans-Peter Nilsson wrote: From: Ulrich Weigand uweig...@de.ibm.com Date: Tue, 25 Aug 2015 19:45:06 +0200 However, neither works for the SPU, because in both cases libtool will only do the test whether the target supports the -fPIC option. It will not test whether the target supports dynamic libraries. [ It will do that test; and default to --disable-shared on SPU. That is a no-op for libbacktrace however, since it calls LT_INIT with the disable-shared option anyway. Maybe it shouldn't? Huh? We do want libbacktrace solely as static library, that's the whole point ... I meant that as a *suggestion for a possible workaround* to stop libtool from refusing to compile with PIC, but then I take it you don't need hints to try another angle than adjusting compilation flags. When adding back the -fPIC flag due to either the pic-only LT_INIT option or the -prefer-pic libtool command line option, it does not check for that again. ] Sounds like a bug somewhere, in libtool or its current use: there *should* be a way to specify I'd prefer PIC code in these static libraries. But that's what the option *does*. Let me try again, maybe we can reduce confusion a bit :-) I don't feel very confused, but I understand you've investigated things down to a point where we can conclude that libtool can't do what SPU needs without also at least fiddling with compilation options. I guess we can always fall back to just hard-coding SPU once more; that's certainly the simplest solution right now. Maybe. brgds, H-P
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
Hans-Peter Nilsson wrote: From: Ulrich Weigand uweig...@de.ibm.com Date: Tue, 25 Aug 2015 19:45:06 +0200 However, neither works for the SPU, because in both cases libtool will only do the test whether the target supports the -fPIC option. It will not test whether the target supports dynamic libraries. [ It will do that test; and default to --disable-shared on SPU. That is a no-op for libbacktrace however, since it calls LT_INIT with the disable-shared option anyway. Maybe it shouldn't? Huh? We do want libbacktrace solely as static library, that's the whole point ... When adding back the -fPIC flag due to either the pic-only LT_INIT option or the -prefer-pic libtool command line option, it does not check for that again. ] Sounds like a bug somewhere, in libtool or its current use: there *should* be a way to specify I'd prefer PIC code in these static libraries. But that's what the option *does*. Let me try again, maybe we can reduce confusion a bit :-) We've been discussing three potential sets of options to use with the LT_INIT call here. Those are: A) LT_INIT# no options Build both a static and a shared library. If the target does not support shared libraries, build the static library only. The code landing in the static library is built without -fPIC; code for the shared library is built with -fPIC (or the appropriate target flag). B) LT_INIT([disable-shared]) Build *solely* a static library. Code is compiled without -fPIC. C) LT_INIT([disable-shared,pic-only]) Build solely a static library, but compile code with -fPIC or the appropriate target flag (may be none if the target does not support -fPIC). [Note that in all cases, behaviour can be overridden via configure options like --enable/disable-shared and --enable/disable-static.] As I understand it, we deliberately do not use option A. As the comment in the libbacktrace configure.ac says: # 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. That's why libbacktrace currently uses option B and manually adds a -fPIC flag. Now, after the latest check-in, the behaviour is mostly equivalent to using option C (and not manually changing PIC flags). However, none of the options do exactly what would be right for the SPU, which would be: Build solely a static library, using code that is compiled so that it can be linked as part of a second library (static or shared). This is equivalent to: Build solely a static library, but compile code with -fPIC or the appropriate target flag *if the target supports shared libraries*. This again is *mostly* equivalent to option C, *except* on targets that support -fPIC but do not support shared libraries. I'm not sure if it is worthwhile to try and change libtool to support targets with that property (e.g. adding a new LT_INIT option), if this in practice only affects SPU. But, I'll have to leave solving this PIC-failing-at-linkage problem to you; I committed the current approved fix for PIC-failing-at-compilation. I guess we can always fall back to just hard-coding SPU once more; that's certainly the simplest solution right now. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
[PATCH] Fix and simplify (Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran)
Hans-Peter Nilsson wrote:
I don't feel very confused, but I understand you've investigated
things down to a point where we can conclude that libtool can't
do what SPU needs without also at least fiddling with
compilation options.
Well, looks like I was confused after all. I missed one extra
feature of libtool that does indeed just make everything work
automatically: if a library is set up using the noinst flag,
libtool considers it a convenience library and will never
create a shared library in any case; but it will create two
sets of object files, one suitable for linking into a static
library and one suitable for linking into a shared library,
and will automatically use the correct set when linking any
other library against the convenince library.
This is exactly what we want to happen for libbacktrace. And
in fact, it is *already* set up as convenience library:
noinst_LTLIBRARIES = libbacktrace.la
This means the only thing we need to do is simply remove all
the special code: no more disable-shared and no more fiddling
with -fPIC (except for the --enable-host-shared case, which
remains special just like it does in all other libraries).
I've verified that this works on x86_64: the resulting
libgfortran.so uses the -fPIC version of the libbacktrace
object, while libgfortran.a uses the non-PIC versions.
On SPU, libtool will now automatically only generate the
non-PIC versions since the target does not support shared
library. So everything works as expected.
OK for mainline?
Bye,
Ulrich
Index: libbacktrace/configure.ac
===
--- libbacktrace/configure.ac (revision 227217)
+++ libbacktrace/configure.ac (working copy)
@@ -79,7 +79,7 @@ case $AWK in
) AC_MSG_ERROR([can't build without awk]) ;;
esac
-LT_INIT([disable-shared])
+LT_INIT
AM_PROG_LIBTOOL
backtrace_supported=yes
@@ -161,22 +161,11 @@ else
fi
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, if
-# the target supports compiling with that option.
-PIC_FLAG=
-if test -n ${with_target_subdir}; then
- ac_save_CFLAGS=$CFLAGS
- CFLAGS=$CFLAGS -fPIC
- AC_TRY_COMPILE([], [], [PIC_FLAG=-fPIC])
- CFLAGS=$ac_save_CFLAGS
-fi
-# Similarly, use -fPIC with --enable-host-shared:
+# Enable --enable-host-shared.
AC_ARG_ENABLE(host-shared,
[AS_HELP_STRING([--enable-host-shared],
[build host code as shared libraries])],
-[PIC_FLAG=-fPIC], [])
+[PIC_FLAG=-fPIC], [PIC_FLAG=])
AC_SUBST(PIC_FLAG)
# Test for __sync support.
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Re: [PATCH] Fix and simplify (Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran)
Ulrich Weigand uweig...@de.ibm.com writes: I've verified that this works on x86_64: the resulting libgfortran.so uses the -fPIC version of the libbacktrace object, while libgfortran.a uses the non-PIC versions. On SPU, libtool will now automatically only generate the non-PIC versions since the target does not support shared library. So everything works as expected. OK for mainline? Can you verify that libgo works as expected? Ian
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
Hans-Peter Nilsson wrote: From: Ulrich Weigand uweig...@de.ibm.com Date: Tue, 25 Aug 2015 14:59:05 +0200 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.) Well, the figuring out is implicit; because libtool knows the platform does not support dynamic linking, it defaults to --disable-shared, which means only static libraries are being built; and the default compile option when building static libraries does not use -fPIC. 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? Hmm, reading the documentation an even simpler version that has equivalent effect to yours should be just adding the pic-only option when calling LT_INIT. However, neither works for the SPU, because in both cases libtool will only do the test whether the target supports the -fPIC option. It will not test whether the target supports dynamic libraries. [ It will do that test; and default to --disable-shared on SPU. That is a no-op for libbacktrace however, since it calls LT_INIT with the disable-shared option anyway. When adding back the -fPIC flag due to either the pic-only LT_INIT option or the -prefer-pic libtool command line option, it does not check for that again. ] Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
TL;DR: See last...
From: Ulrich Weigand uweig...@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.0 +0200
+++ libbacktrace/configure.ac 2015-08-24 17:31:18.0 +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
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
Ian Lance Taylor wrote: Hans-Peter Nilsson hans-peter.nils...@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.weig...@de.ibm.com
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
From: Ulrich Weigand uweig...@de.ibm.com Date: Tue, 25 Aug 2015 19:45:06 +0200 Hans-Peter Nilsson wrote: However, neither works for the SPU, because in both cases libtool will only do the test whether the target supports the -fPIC option. It will not test whether the target supports dynamic libraries. [ It will do that test; and default to --disable-shared on SPU. That is a no-op for libbacktrace however, since it calls LT_INIT with the disable-shared option anyway. Maybe it shouldn't? When adding back the -fPIC flag due to either the pic-only LT_INIT option or the -prefer-pic libtool command line option, it does not check for that again. ] Sounds like a bug somewhere, in libtool or its current use: there *should* be a way to specify I'd prefer PIC code in these static libraries. But, I'll have to leave solving this PIC-failing-at-linkage problem to you; I committed the current approved fix for PIC-failing-at-compilation. brgds, H-P
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
PIC_FLAG=
if test -n ${with_target_subdir}; then
- PIC_FLAG=-fPIC
+ AC_TRY_COMPILE([void foo(void){}], [PIC_FLAG=-fPIC])
fi
There’s something I don’t understand about this test. Shouldn’t AC_TRY_COMPILE
take a first (empty) argument, “includes”? And shouldn’t you first set the
-fPIC flag before try to compile with that?
FX
Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
There exists targets that support fortran but error on -fPIC,
for example cris-elf, which broke with the libbacktrace thingy.
(Emitting an error for -fPIC is a conscious choice; a
compilation error is better than e.g. to silently ignoring it.)
This fix causes build to pass the point of error for cris-elf.
Borderline obvious, but...
Ok to regtest passes on a native x86_64-linux?
libbacktrace:
configure.ac: Only compile with -fPIC if the target
supports it.
diff -upr /expvol/pp_slask/hp/checkout/gcchead/gcc/libbacktrace/configure.ac
libbacktrace/configure.ac
--- /expvol/pp_slask/hp/checkout/gcchead/gcc/libbacktrace/configure.ac
2015-05-29 17:23:20.0 +0200
+++ libbacktrace/configure.ac 2015-08-24 17:31:18.0 +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 just compile with -fPIC, if
+# the target supports compiling a function with that option.
PIC_FLAG=
if test -n ${with_target_subdir}; then
- PIC_FLAG=-fPIC
+ AC_TRY_COMPILE([void foo(void){}], [PIC_FLAG=-fPIC])
fi
# Similarly, use -fPIC with --enable-host-shared:
AC_ARG_ENABLE(host-shared,
brgds, H-P
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
From: FX fxcoud...@gmail.com
Date: Mon, 24 Aug 2015 18:07:52 +0200
PIC_FLAG=
if test -n ${with_target_subdir}; then
- PIC_FLAG=-fPIC
+ AC_TRY_COMPILE([void foo(void){}], [PIC_FLAG=-fPIC])
fi
There's something I don't understand about this
test. Shouldn't AC_TRY_COMPILE take a first (empty) argument,
includes? And shouldn't you first set the -fPIC flag before
try to compile with that?
You're absolutely right on both accounts. Also, the function
body is supposed to be a function body (...) or else we get a
nested function (i.e. foo inside main). Might as well provide
both empty. Also fixing the ChangeLog entry. Sorry for
goofing. (At least I had a look at config.log this time...)
* configure.ac: Only compile with -fPIC if the target
supports it.
* configure: Regenerate.
diff -upr /expvol/pp_slask/hp/checkout/gcchead/gcc/libbacktrace/configure.ac
libbacktrace/configure.ac
--- /expvol/pp_slask/hp/checkout/gcchead/gcc/libbacktrace/configure.ac
2015-05-29 17:23:20.0 +0200
+++ libbacktrace/configure.ac 2015-08-24 18:31:01.0 +0200
@@ -163,10 +163,14 @@ 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 just compile with -fPIC, if
+# the target supports compiling with that option.
PIC_FLAG=
if test -n ${with_target_subdir}; then
- PIC_FLAG=-fPIC
+ ac_save_CFLAGS=$CFLAGS
+ CFLAGS=$CFLAGS -fPIC
+ AC_TRY_COMPILE([], [], [PIC_FLAG=-fPIC])
+ CFLAGS=$ac_save_CFLAGS
fi
# Similarly, use -fPIC with --enable-host-shared:
AC_ARG_ENABLE(host-shared,
brgds, H-P
Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
(Goofed on the CC line, sorry for the dup.)
There exists targets that support fortran but error on -fPIC,
for example cris-elf, which broke with the libbacktrace thingy.
(Emitting an error for -fPIC is a conscious choice; a
compilation error is better than e.g. to silently ignoring it.)
This fix causes build to pass the point of error for cris-elf.
Borderline obvious, but...
Ok to regtest passes on a native x86_64-linux?
libbacktrace:
configure.ac: Only compile with -fPIC if the target
supports it.
diff -upr /expvol/pp_slask/hp/checkout/gcchead/gcc/libbacktrace/configure.ac
libbacktrace/configure.ac
--- /expvol/pp_slask/hp/checkout/gcchead/gcc/libbacktrace/configure.ac
2015-05-29 17:23:20.0 +0200
+++ libbacktrace/configure.ac 2015-08-24 17:31:18.0 +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 just compile with -fPIC, if
+# the target supports compiling a function with that option.
PIC_FLAG=
if test -n ${with_target_subdir}; then
- PIC_FLAG=-fPIC
+ AC_TRY_COMPILE([void foo(void){}], [PIC_FLAG=-fPIC])
fi
# Similarly, use -fPIC with --enable-host-shared:
AC_ARG_ENABLE(host-shared,
brgds, H-P
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
You're absolutely right on both accounts. Also, the function body is supposed to be a function body (...) or else we get a nested function (i.e. foo inside main). Might as well provide both empty. Also fixing the ChangeLog entry. Sorry for goofing. (At least I had a look at config.log this time…) That looks better :) But I can’t approve the patch. FX
Re: Fix libbacktrace -fPIC breakage from Use libbacktrace in libgfortran
Hans-Peter Nilsson hans-peter.nils...@axis.com writes: * configure.ac: Only compile with -fPIC if the target supports it. * configure: Regenerate. This is OK. Thanks. Ian
