[Bug ld/14788] trying to link simple ifunc test causes the linker to segfault with s390x targets
http://sourceware.org/bugzilla/show_bug.cgi?id=14788 Andreas Krebbel changed: What|Removed |Added Status|NEW |ASSIGNED CC||krebbel at linux dot ||vnet.ibm.com AssignedTo|unassigned at sourceware|krebbel at linux dot |dot org |vnet.ibm.com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14788] trying to link simple ifunc test causes the linker to segfault with s390x targets
http://sourceware.org/bugzilla/show_bug.cgi?id=14788 --- Comment #1 from Andreas Krebbel 2012-11-05 09:38:06 UTC --- Created attachment 6716 --> http://sourceware.org/bugzilla/attachment.cgi?id=6716 Proposed fix This fixes the problem for me. I'll commit it to mainline asap. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18378] Implement GOLD backend support for IBM z Systems
https://sourceware.org/bugzilla/show_bug.cgi?id=18378 Andreas Krebbel changed: What|Removed |Added CC||krebbel at linux dot vnet.ibm.com --- Comment #4 from Andreas Krebbel --- (In reply to eduard.beutel from comment #3) Starting in June there will be a new way of getting access to z Systems hardware. I'll post the information here as soon as I know more. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18378] Implement GOLD backend support for IBM z Systems
https://sourceware.org/bugzilla/show_bug.cgi?id=18378 --- Comment #6 from Andreas Krebbel --- (In reply to Andreas Krebbel from comment #0) IBM has created a bounty on this item at: https://www.bountysource.com/issues/14306991-implement-gold-backend-support-for-ibm-z-systems Part of the success criteria is that all required patches for this feature are accepted and integrated into the Binutils source repository. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/14940] s390 -pie issues with TLS relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=14940 Andreas Krebbel changed: What|Removed |Added Status|NEW |RESOLVED CC||krebbel at linux dot vnet.ibm.com Resolution|--- |FIXED --- Comment #1 from Andreas Krebbel --- (In reply to Jakub Jelinek from comment #0) > While this is now fixed on i?86/x86_64 and perhaps ppc/ppc64, it isn't fixed > on s390/s390x. See https://bugzilla.redhat.com/show_bug.cgi?id=872148 Should be fixed with: https://sourceware.org/ml/binutils/2014-09/msg00067.html -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18378] Implement GOLD backend support for IBM z Systems
https://sourceware.org/bugzilla/show_bug.cgi?id=18378 --- Comment #12 from Andreas Krebbel --- (In reply to Marcin Kościelnicki from comment #11) > Does that look OK? Great! Looks good to me from a first glance, but I'll need some time to actually do a review. Could you please post the patches on the binutils mailing list to allow other maintainers have a look? Thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18378] Implement GOLD backend support for IBM z Systems
https://sourceware.org/bugzilla/show_bug.cgi?id=18378 --- Comment #15 from Andreas Krebbel --- (In reply to Marcin Kościelnicki from comment #13) > Created attachment 8609 [details] > patch #4 - the main course (with 32-bit PLT fix) > > One fix added: I found a bug in handling of PLT entries with plt_offset == > 0x1 for 32-bit target. Thanks! I've found your github repo of the S/390 gold port: https://github.com/koriakin/binutils-gdb.git Is this supposed to be up-to-date so that I can base my review and test on that? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19073] New: ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073 Bug ID: 19073 Summary: ld: Segmentation fault building Glibc Product: binutils Version: 2.26 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: krebbel at linux dot vnet.ibm.com Target Milestone: --- Binutils cannot be used to build Glibc since this commit: commit 422f11824b3abf6c71042e2ee3aed572f250fc89 Author: H.J. Lu Date: Mon Aug 10 07:57:40 2015 -0700 Replace hidden with versioned in elf_link_hash_entry This patch replaces the "hidden" field with the "versioned" field in elf_link_hash_entry so that we can avoid calling strchr and strrchr if the symbol is unversioned. * elf-bfd.h (elf_symbol_version): New enum. (elf_link_hash_entry): Replace hidden with versioned. * elflink.c (_bfd_elf_merge_symbol): Don't look for symbol version if the symbol is unversioned. Initialize versioned. (_bfd_elf_add_default_symbol): Don't look for symbol version if the symbol is unversioned or hidden. Initialize versioned. (elf_collect_hash_codes): Don't look for symbol version if the symbol is unversioned. (elf_collect_gnu_hash_codes): Likewise. (bfd_elf_gc_mark_dynamic_ref_symbol): Likewise. (_bfd_elf_link_hash_copy_indirect): Check versioned instead of hidden. (elf_link_output_extsym): Likewise. gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld64.so.1 -B/home/andreas/glibc/glibc-06102015-build/csu/ -Wl,--version-script=/home/andreas/glibc/glibc-06102015-build/libc.map -Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/home/andreas/glibc/glibc-06102015-build -L/home/andreas/glibc/glibc-06102015-build/math -L/home/andreas/glibc/glibc-06102015-build/elf -L/home/andreas/glibc/glibc-06102015-build/dlfcn -L/home/andreas/glibc/glibc-06102015-build/nss -L/home/andreas/glibc/glibc-06102015-build/nis -L/home/andreas/glibc/glibc-06102015-build/rt -L/home/andreas/glibc/glibc-06102015-build/resolv -L/home/andreas/glibc/glibc-06102015-build/crypt -L/home/andreas/glibc/glibc-06102015-build/mathvec -L/home/andreas/glibc/glibc-06102015-build/nptl -Wl,-rpath-link=/home/andreas/glibc/glibc-06102015-build:/home/andreas/glibc/glibc-06102015-build/math:/home/andreas/glibc/glibc-06102015-build/elf:/home/andreas/glibc/glibc-06102015-build/dlfcn:/home/andreas/glibc/glibc-06102015-build/nss:/home/andreas/glibc/glibc-06102015-build/nis:/home/andreas/glibc/glibc-06102015-build/rt:/home/andreas/glibc/glibc-06102015-build/resolv:/home/andreas/glibc/glibc-06102015-build/crypt:/home/andreas/glibc/glibc-06102015-build/mathvec:/home/andreas/glibc/glibc-06102015-build/nptl -o /home/andreas/glibc/glibc-06102015-build/libc.so -T /home/andreas/glibc/glibc-06102015-build/shlib.lds /home/andreas/glibc/glibc-06102015-build/csu/abi-note.o /home/andreas/glibc/glibc-06102015-build/elf/soinit.os /home/andreas/glibc/glibc-06102015-build/libc_pic.os /home/andreas/glibc/glibc-06102015-build/elf/sofini.os /home/andreas/glibc/glibc-06102015-build/elf/interp.os /home/andreas/glibc/glibc-06102015-build/elf/ld.so -lgcc /bin/sh ../scripts/rellns-sh /home/andreas/glibc/glibc-06102015-build/elf/ld.so /home/andreas/glibc/glibc-06102015-build/elf/ld64.so.1.new mv -f /home/andreas/glibc/glibc-06102015-build/elf/ld64.so.1.new /home/andreas/glibc/glibc-06102015-build/elf/ld64.so.1 collect2: error: ld terminated with signal 11 [Segmentation fault] make[2]: *** [/home/andreas/glibc/glibc-06102015-build/libc.so] Error 1 make[2]: Leaving directory `/home/andreas/glibc/glibc/elf' make[1]: *** [elf/subdir_lib] Error 2 make[1]: Leaving directory `/home/andreas/glibc/glibc' make: *** [all] Error 2 Program received signal SIGSEGV, Segmentation fault. 0x03fffdeb323c in __memcpy_mvcle () from /lib64/libc.so.6 (gdb) bt #0 0x03fffdeb323c in __memcpy_mvcle () from /lib64/libc.so.6 #1 0x8009ae06 in _bfd_elf_add_default_symbol (abfd=0x8022f050, info=0x801be990 , h=0x802b02f8, name=0x8024bab7 "setjmp", sym=0x3fff78d22d0, sec=0x80230320, value=86064, poldbfd=0x3ffddd0, dynsym=0x3ffddc0) at /home/andreas/binutils/binutils/bfd/elflink.c:1724 #2 0x800a1752 in elf_link_add_object_symbols (abfd=0x8022f050, info=0x801be990 ) at /home/andreas/binutils/binutils/bfd/elflink.c:4375 #3 0x800a3918 in bfd_elf_link_add_symbols (abfd=0x8022f050, info=0x801be990 ) at /home/andreas/binutils/binutils/bfd/elflink.c:5241 #4 0x80015580 in load_symbols (entry=0x801c0328, place=0x3ffe438) at /home/andreas/binutils/binutils/ld/ldlang.c:2854 #5 0x80016790 in open_input_bfds (s=0x801c0328, mode=OPEN_BFD_NORMAL) at /home/andreas/binut
[Bug ld/19073] ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073 Andreas Krebbel changed: What|Removed |Added Target||s390x-ibm-linux Host||s390x-ibm-linux Build||s390x-ibm-linux --- Comment #2 from Andreas Krebbel --- (In reply to H.J. Lu from comment #1) > I can build glibc master branch with binutils 2.25.51.20151006 on > x86 and x86-64. What target were you building for? s390x - I definitely should have mentioned this - sorry -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19073] S/390: ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073 Andreas Krebbel changed: What|Removed |Added Summary|ld: Segmentation fault |S/390: ld: Segmentation |building Glibc |fault building Glibc -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19073] S/390: ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073 Andreas Krebbel changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19073] S/390: ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073 --- Comment #4 from Andreas Krebbel --- (gdb) p name $1 = 0x8024eab7 "setjmp" (gdb) p shortname $2 = 0x3ff77b15020 "setjmp" (gdb) p shortlen $3 = 18446744071559648585 (gdb) l 1722 1723 shortlen = p - name; 1724 shortname = (char *) bfd_hash_allocate (&info->hash->table, shortlen + 1); 1725 if (shortname == NULL) 1726return FALSE; 1727 memcpy (shortname, name, shortlen); 1728 shortname[shortlen] = '\0'; 1729 1730 /* We are going to create a new symbol. Merge it with any existing 1731 symbol with this name. For the purposes of the merge, act as (gdb) p p $4 = 0x0 (gdb) p name $5 = 0x8024eab7 "setjmp" (gdb) p h->versioned $6 = versioned The problem is that there might be symbols marked as versioned but without having @ in its names. p is NULL then. We have that with setjmp in Glibc: 234157: 00015030 8 FUNCWEAK DEFAULT2 setjmp@@GLIBC_2.2 234509: 00015030 8 FUNCWEAK DEFAULT2 setjmp -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19073] S/390: ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073 --- Comment #6 from Andreas Krebbel --- Created attachment 8701 --> https://sourceware.org/bugzilla/attachment.cgi?id=8701&action=edit Testcase - reduced input file from glibc With this testcase the failing symbol is getcontext: 16488: 106 FUNCWEAK DEFAULT2 __v1__getcontext 16534: 106 FUNCGLOBAL DEFAULT2 __getcontext 16562: 106 FUNCWEAK DEFAULT2 getcontext@@GLIBC_2.2 16570: 106 FUNCWEAK DEFAULT2 getcontext@GLIBC_2.19 16589: 106 FUNCWEAK DEFAULT2 __v2__getcontext 16660: 106 FUNCWEAK DEFAULT2 getcontext getcontext (as well as setjmp and others) on S/390 default to an older symbol version in order to avoid the buggy versions in Glibc 2.19. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19083] [s390] ld internal error in elf_s390_relocate_section when compiling systemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19083 Andreas Krebbel changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |krebbel at linux dot vnet.ibm.com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19083] [s390] ld internal error in elf_s390_relocate_section when compiling systemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19083 Andreas Krebbel changed: What|Removed |Added CC||krebbel at linux dot vnet.ibm.com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19073] S/390: ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073 --- Comment #8 from Andreas Krebbel --- (In reply to H.J. Lu from comment #7) > Please provide a testcase I can reproduce it on x86-64 with > only cross binutils. The testcase I've attached fails the same way with cross binutils: install-s390x/bin/s390x-ibm-linux-ld -melf64_s390 b.os Segmentation fault (core dumped) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19073] S/390: ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073 --- Comment #9 from Andreas Krebbel --- The problem is that when processing "getcontext" in elf_link_add_object_symbols it is matched by the hash entry for "getcontext@@GLIBC_2.2" here: /* We need to make sure that indirect symbol dynamic flags are updated. */ hi = h; while (h->root.type == bfd_link_hash_indirect || h->root.type == bfd_link_hash_warning) h = (struct elf_link_hash_entry *) h->root.u.i.link; While the name stays "getcontext" the new `h' has the `versioned' flag set. That's what confuses _bfd_elf_add_default_symbol. This hack mimics the old behavior of exiting for all symbols not having @ in their name and fixes the problem for me: diff --git a/bfd/elflink.c b/bfd/elflink.c index 94bb710..2a56fd6 100644 --- a/bfd/elflink.c +++ b/bfd/elflink.c @@ -4374,8 +4374,9 @@ error_free_dyn: /* Check to see if we need to add an indirect symbol for the default name. */ - if (definition - || (!override && h->root.type == bfd_link_hash_common)) + if (strchr (name, ELF_VER_CHR) != NULL + && (definition + || (!override && h->root.type == bfd_link_hash_common))) if (!_bfd_elf_add_default_symbol (abfd, info, h, name, isym, sec, value, &old_bfd, &dynsym)) goto error_free_vers; -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19083] [s390] ld internal error in elf_s390_relocate_section when compiling systemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19083 Andreas Krebbel changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Andreas Krebbel --- Fixed per comment above. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19073] S/390: ld: Segmentation fault building Glibc
https://sourceware.org/bugzilla/show_bug.cgi?id=19073
--- Comment #13 from Andreas Krebbel ---
(In reply to H.J. Lu from comment #10)
> (In reply to Andreas Krebbel from comment #8)
> > (In reply to H.J. Lu from comment #7)
> > > Please provide a testcase I can reproduce it on x86-64 with
> > > only cross binutils.
> >
> > The testcase I've attached fails the same way with cross binutils:
> >
> > install-s390x/bin/s390x-ibm-linux-ld -melf64_s390 b.os
> > Segmentation fault (core dumped)
>
> [hjl@gnu-6 pr19073]$ cat xxx.c
> void
> __foo ()
> {
> }
>
> asm (".weak foo_v1");
> asm (".globl foo_v1");
> asm (".set foo_v1, __foo");
> asm (".weak foo_v2");
> asm (".globl foo_v2");
> asm (".set foo_v2, __foo");
> asm (".symver foo_v2,foo@VERS.2");
> asm (".symver foo_v1,foo@@VERS.1");
> asm (".globl foo");
> asm (".weak foo");
> asm (".set foo, __foo");
> [hjl@gnu-6 pr19073]$ make libfoo.so
> gcc -B./ -fPIC -c -o xxx.o xxx.c
> ./ld -o foo.o -r xxx.o
> ./ld -o libfoo.so -shared foo.o --version-script foo.v
> Makefile:12: recipe for target 'libfoo.so' failed
> make: *** [libfoo.so] Segmentation fault
> make: *** Deleting file 'libfoo.so'
> [hjl@gnu-6 pr19073]$
>
> There is a bug in sysdeps/unix/sysv/linux/s390/s390-64/getcontext.S
> which defines both getcontext@@GLIBC_2.2 and getcontext. But linker
> shouldn't crash.
I agree that this does not look correct but it is similiar to e.g. setjmp on
x86_64:
readelf -s libc.so.6 | grep " setjmp"
622: 00032ce010 FUNCGLOBAL DEFAULT 13 setjmp@@GLIBC_2.2.5
6015: 00032ce010 FUNCGLOBAL DEFAULT 13 setjmp
One difference appears to be that the symbol without version information is
weak on s390.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19083] [s390] ld internal error in elf_s390_relocate_section when compiling systemd
https://sourceware.org/bugzilla/show_bug.cgi?id=19083 Andreas Krebbel changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Andreas Krebbel --- Closed per comment above. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18378] Implement GOLD backend support for IBM z Systems
https://sourceware.org/bugzilla/show_bug.cgi?id=18378 Andreas Krebbel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Andreas Krebbel --- Resolved per comment above -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18378] Implement GOLD backend support for IBM z Systems
https://sourceware.org/bugzilla/show_bug.cgi?id=18378 Andreas Krebbel changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #27 from Andreas Krebbel --- Closing -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19579] [Regression] link error linking fortran code on s390x-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=19579
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at linux dot
vnet.ibm.com
--- Comment #5 from Andreas Krebbel ---
I can reproduce the failure building mopac7-1.15 with -fPIC and -pie. The
problem disappears when omitting -pie.
The error gets reported after elf_s390_finish_dynamic_symbol returned false
here:
else if (bfd_link_pic (info)
&& SYMBOL_REFERENCES_LOCAL (info, h))
{
/* If this is a static link, or it is a -Bsymbolic link and
the symbol is defined locally or was forced to be local
because of a version file, we just want to emit a
RELATIVE reloc. The entry in the global offset table
will already have been initialized in the
relocate_section function. */
> if (!h->def_regular)
return FALSE;
The symbol in question is geovar_ :
$ readelf -s ./.libs/libmopac7.so | grep geovar_
388: 0399f920 8656 OBJECT GLOBAL DEFAULT 22 geovar_
5819: 0399f920 8656 OBJECT GLOBAL DEFAULT 22 geovar_
$ readelf -s mopac7app.o | grep geovar
160: 0008 5768 OBJECT GLOBAL DEFAULT COM geovar_
It is not clear to me yet how this is supposed to work correctly yet. As usual
I've tried to figure out what x86 is doing but I ran into similiar problems:
with 2.23.52 I see the very same problem as on s390:
/bin/sh ../libtool --tag=F77 --mode=link gfortran -g -O2 -std=legacy
-fno-automatic -fPIC -lm -Wl,--
gfortran -g -O2 -std=legacy -fno-automatic -fPIC -Wl,--as-needed -Wl,-z
-Wl,defs -pie -o .libs/mopac7 m
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[1]: *** [mopac7] Error 1
Using head binutils however I get:
gfortran -g -O2 -std=legacy -fno-automatic -fPIC -Wl,--as-needed -Wl,-z
-Wl,defs -pie -o .libs/mopac7 mopac7app.o ./.libs/libmopac7.so -lm
-Wl,--rpath -Wl,/home/andreas/mopac/install/lib
/home/andreas/binutils/binutils-26022016-install/bin/ld: mopac7app.o:
relocation R_X86_64_PC32 against undefined symbol `geokst_' can not be used
when making a shared object; recompile with -fPIC
/home/andreas/binutils/binutils-26022016-install/bin/ld: final link failed: Bad
value
Although everything is built with -fPIC
I'll continue next week.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19579] [Regression] link error linking fortran code on s390x-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=19579 --- Comment #7 from Andreas Krebbel --- (In reply to H.J. Lu from comment #6) > I can reproduce it on Fedora 23. It is a bug in redhat-rpm-config, which > has redhat-hardened-cc1 and redhat-hardened-ld. But there is no > redhat-hardened-f951. mopac7app.o isn't compiled with PIE/PIC. In my tests mopac7app.o was built with -fPIC. The problem seems to occur since this commit: commit b31bcacc489d6ede2e9bdfa9905de0ebfd919454 Author: H.J. Lu Date: Fri Oct 16 03:14:40 2015 -0700 Convert mov to lea for loading address of local common symbol There is no need to check def_regular when converting mov to lea for loading address of local symbols since def_regular may be false for common symbols and SYMBOL_REFERENCES_LOCAL is sufficient. bfd/ * elf32-i386.c (elf_i386_convert_mov_to_lea): Don't check def_regular. * elf64-x86-64.c (elf_x86_64_convert_mov_to_lea): Likewise. Before that change there was the same problem is currently on S/390: /bin/sh ../libtool --tag=F77 --mode=link gfortran -g -O2 -std=legacy -fno-automatic -fPIC -lm -Wl,--as-needed -Wl,-z,defs -pie -o mopac7 mopac7app.o libmopac7.la -lm gfortran -g -O2 -std=legacy -fno-automatic -fPIC -Wl,--as-needed -Wl,-z -Wl,defs -pie -o .libs/mopac7 mopac7app.o ./.libs/libmopac7.so -lm -Wl,--rpath -Wl,/home/andreas/mopac/install/lib /home/andreas/binutils/binutils-before-install/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status make[1]: *** [mopac7] Error 1 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19579] [Regression] link error linking fortran code with PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=19579 Andreas Krebbel changed: What|Removed |Added Status|WAITING |NEW --- Comment #13 from Andreas Krebbel --- (In reply to H.J. Lu from comment #12) > Created attachment 9061 [details] > A new patch Problem is fixed on s390 with this patch. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21333] s390x GNU as uses symbol relocations for .debug_info
https://sourceware.org/bugzilla/show_bug.cgi?id=21333 Andreas Krebbel changed: What|Removed |Added CC||krebbel at linux dot vnet.ibm.com --- Comment #2 from Andreas Krebbel --- Should be ok for s390 as well. Given that we mimic the i386 binutils code in many other situations I don't see why we should stop here ;) Thanks for having a look! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
