| Message ID | 1323228983-27811-1-git-send-email-vapier@gentoo.org |
|---|---|
| State | New |
| Headers | show |
Mike Frysinger <vapier@gentoo.org> writes: > Building newer libiberty for s390x targets fails with relocation errors: > libiberty/pic/libiberty.a(hashtab.o): In function 'htab_create': > libiberty/hashtab.c:408:(.text+0x5e4): relocation truncated to fit: > R_390_GOT12 against symbol 'xcalloc' defined in .text section in > libiberty/pic/libiberty.a(xmalloc.o) > libiberty/pic/libiberty.a(hashtab.o): In function 'htab_try_create': > libiberty/hashtab.c:414:(.text+0x61c): relocation truncated to fit: > R_390_GOT12 against symbol 'calloc@@GLIBC_2.2' defined in .text > section in /lib/libc.so.6 > collect2: ld returned 1 exit status > > Building with larger GOT (-fPIC rather than -fpic) fixes this. > > CC: Aurelien Jarno <aurelien@aurel32.net> > CC: Martin Schwidefsky <schwidefsky@de.ibm.com> > Signed-off-by: Mike Frysinger <vapier@gentoo.org> > > config/: > 2011-12-06 Mike Frysinger <vapier@gentoo.org> > > * picflag.m4 (_GCC_PICFLAG): Set $1 to -fPIC for s390x*-*-*. > > gcc/: > libada/: > libgcc/: > libiberty/: > 2011-12-06 Mike Frysinger <vapier@gentoo.org> > > * configure: Regenerate. > --- > config/picflag.m4 | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/config/picflag.m4 b/config/picflag.m4 > index f6f1b44..db2ce0f 100644 > --- a/config/picflag.m4 > +++ b/config/picflag.m4 > @@ -51,6 +51,9 @@ case "${$2}" in > m68k-*-*) > $1=-fpic > ;; > + s390x*-*-*) > + $1=-fpic > + ;; This doesn't match the ChangeLog/description, and certainly needs an explanation. > s390*-*-*) > $1=-fpic > ;; Perhaps it's better to remove both s390* cases and use the -fPIC default everywhere, as does libtool. picflag.m4 is supposed to be usable everywhere. Rainer
On Wed, 07 Dec 2011 10:33:54 +0100 Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote: > Mike Frysinger <vapier@gentoo.org> writes: > > > s390*-*-*) > > $1=-fpic > > ;; > > Perhaps it's better to remove both s390* cases and use the -fPIC default > everywhere, as does libtool. picflag.m4 is supposed to be usable > everywhere. What does "usable everywhere" actually mean, usable everywhere in binutils or usable in any imaginable piece of code? If we are only interested in binutils then -fpic is good enough for 31-bit s390 right now.
Martin Schwidefsky <schwidefsky@de.ibm.com> writes: > On Wed, 07 Dec 2011 10:33:54 +0100 > Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote: > >> Mike Frysinger <vapier@gentoo.org> writes: >> >> > s390*-*-*) >> > $1=-fpic >> > ;; >> >> Perhaps it's better to remove both s390* cases and use the -fPIC default >> everywhere, as does libtool. picflag.m4 is supposed to be usable >> everywhere. > > What does "usable everywhere" actually mean, usable everywhere in binutils > or usable in any imaginable piece of code? If we are only interested in > binutils then -fpic is good enough for 31-bit s390 right now. picflag.m4 isn't used only in binutils, but for several gcc libraries as well. That's why I'm arguing to use a safe default (-fPIC) if feasible, rather than adjusting/overriding whenever -fpic breaks. Overrides like in libgcc/config/s390/t-crtstuff don't seem particularly useful to me, especially when done with no explanation as I suggested when that patch went in. Rainer
On 12/07/2011 10:33 AM, Rainer Orth wrote: > Mike Frysinger <vapier@gentoo.org> writes: >> s390*-*-*) >> $1=-fpic >> ;; > > Perhaps it's better to remove both s390* cases and use the -fPIC default > everywhere, as does libtool. picflag.m4 is supposed to be usable > everywhere. From a performance perspective the "fix after breakage" approach still would make sense since GCC generates slightly faster code with -fpic compared to -fPIC. On the other hand the user visible shared libs like libgomp, libgfortran, and libstdc++ are already built with -fPIC anyway. We recently also enabled -fPIC for libgcc_s.so. And now we are about to do the same for libiberty. So I think there does not remain much anyway - or am I missing something?! So I agree that removing the s390*-*-* case entirely in picflag.m4 will be the better way to fix this. We then also should revert that one: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00643.html Bye, -Andreas-
diff --git a/config/picflag.m4 b/config/picflag.m4 index f6f1b44..db2ce0f 100644 --- a/config/picflag.m4 +++ b/config/picflag.m4 @@ -51,6 +51,9 @@ case "${$2}" in m68k-*-*) $1=-fpic ;; + s390x*-*-*) + $1=-fpic + ;; s390*-*-*) $1=-fpic ;;
Building newer libiberty for s390x targets fails with relocation errors: libiberty/pic/libiberty.a(hashtab.o): In function 'htab_create': libiberty/hashtab.c:408:(.text+0x5e4): relocation truncated to fit: R_390_GOT12 against symbol 'xcalloc' defined in .text section in libiberty/pic/libiberty.a(xmalloc.o) libiberty/pic/libiberty.a(hashtab.o): In function 'htab_try_create': libiberty/hashtab.c:414:(.text+0x61c): relocation truncated to fit: R_390_GOT12 against symbol 'calloc@@GLIBC_2.2' defined in .text section in /lib/libc.so.6 collect2: ld returned 1 exit status Building with larger GOT (-fPIC rather than -fpic) fixes this. CC: Aurelien Jarno <aurelien@aurel32.net> CC: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> config/: 2011-12-06 Mike Frysinger <vapier@gentoo.org> * picflag.m4 (_GCC_PICFLAG): Set $1 to -fPIC for s390x*-*-*. gcc/: libada/: libgcc/: libiberty/: 2011-12-06 Mike Frysinger <vapier@gentoo.org> * configure: Regenerate. --- config/picflag.m4 | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)