[Bug ld/9843] New: relocation R_386_GOTOFF against undefined hidden symbol '_begin' can not be used when making a shared object
during build glibc-2.8 for i486-gnu-linux target i get following linker error: (...) make[3]: Leaving directory `/home/users/pluto/alatek/toolchain/branches/4.3/glibc-2.8/elf' i486-gnu-linux-gcc -Wl,--hash-style=both -nostdlib -nostartfiles -shared -Wl,-z,now\ -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs -Wl,--verbose 2>&1 | \ LC_ALL=C \ sed -e '/^=/,/^=/!d;/^=/d'\ -e 's/\. = 0 + SIZEOF_HEADERS;/& _begin = . - SIZEOF_HEADERS;/' \ > /home/users/pluto/alatek/toolchain/branches/4.3/glibc-2.8/BUILDDIR/elf/ld.so.lds i486-gnu-linux-gcc -Wl,--hash-style=both -nostdlib -nostartfiles -shared -o /home/users/pluto/alatek/toolchain/branches/4.3/glibc-2.8/BUILDDIR/elf/ld.so \ -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,now\ /home/users/pluto/alatek/toolchain/branches/4.3/glibc-2.8/BUILDDIR/elf/librtld.os -Wl,--version-script=/home/users/pluto/alatek/toolchain/branches/4.3/glibc-2.8/BUILDDIR/ld.map \ -Wl,-soname=ld-linux.so.2 -T /home/users/pluto/alatek/toolchain/branches/4.3/glibc-2.8/BUILDDIR/elf/ld.so.lds /home/users/pluto/alatek/toolchain/branches/4.3/glibc-2.8/BUILDDIR/elf/librtld.os: In function `_dl_start': rtld.c:(.text+0x3b8): undefined reference to `_begin' /local/devel/toolchain43/i486-gnu-linux.host64/lib/gcc/i486-gnu-linux/4.3.3/../../../../i486-gnu-linux/bin/ld: /home/users/pluto/alatek/toolchain/branches/4.3/glibc-2.8/BUILDDIR/elf/librtld.os: relocation R_386_GOTOFF against undefined hidden symbol `_begin' can not be used when making a shared object /local/devel/toolchain43/i486-gnu-linux.host64/lib/gcc/i486-gnu-linux/4.3.3/../../../../i486-gnu-linux/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status i486-gnu-linux-ld --version GNU ld (Linux/GNU Binutils) 2.19.51.0.2.20090204 note, that previous version (2.19.51.0.1) works fine. -- Summary: relocation R_386_GOTOFF against undefined hidden symbol '_begin' can not be used when making a shared object Product: binutils Version: 2.19 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: pluto at agmk dot net CC: bug-binutils at gnu dot org GCC target triplet: i486-gnu-linux http://sourceware.org/bugzilla/show_bug.cgi?id=9843 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/9811] export table broken after forward (dlltool)
--- Additional Comments From mail at colinfinck dot de 2009-02-14 14:17 --- Thanks for the quick patch! I tried it now, but unfortunately, it looks like importing from any file other than a .dll is generally unsupported by Windows' ntdll. Whatever I do, it always tries to import from "winspool.dll" in my test case, and this file doesn't exist of course. I guess, I need to look for another way then, it won't work with forwarding. All in all, sorry for this bug report. I believe, it can be closed as INVALID. -- http://sourceware.org/bugzilla/show_bug.cgi?id=9811 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/9843] relocation R_386_GOTOFF against undefined hidden symbol '_begin' can not be used when making a shared object
--- Additional Comments From schwab at suse dot de 2009-02-14 14:18 --- (In reply to comment #0) > sed -e '/^=/,/^=/!d;/^=/d'\ > -e 's/\. = 0 + SIZEOF_HEADERS;/& _begin = . - > SIZEOF_HEADERS;/' \ This command is broken and has already been fixed in the glibc repository. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=9843 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/9841] avr-ld crashes when -relax is used with ATMega8535 target
--- Additional Comments From bjoern dot m dot haase at web dot de 2009-02-14 16:19 --- Subject: Re: avr-ld crashes when -relax is used with ATMega8535 target j at uriah dot heep dot sax dot de schrieb: Hallo Jörg, ich werde mir den Bug einmal ansehen, allerdings muss ich auf meinem neuen Rechner erst einmal wieder die AVR Toolchain bauen. Habe seit langem nichts mehr mit AVRs gemacht. Werde jetzt mit einer 19er binutils und der 4.3.2er GCC Version und dem neuesten avr-libc starten. Brauche ich irgendwelche Sonder-Patches? Grüße, Björn. -- http://sourceware.org/bugzilla/show_bug.cgi?id=9841 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/9841] avr-ld crashes when -relax is used with ATMega8535 target
--- Additional Comments From pwilson at scopuli dot com 2009-02-14 18:41 --- I looked at the context of the call to elf32_avr_relax_delete_bytes() and how symtab_hdr->contents is assigned. I then compared the AVR to other architectures calling their elf32_*_relax_delete_bytes() function, and it appears to me that the AVR relax implementation is based upon the h8300 relax implementation. In fact, I searched for h8300 in elf32-avr.c and found a reference to cut-n-pasting code from the h8300 port. So I looked at the calls to elf32_h8_relax_delete_bytes(), and before every call there are these lines of code: elf_section_data (sec)->relocs = internal_relocs; elf_section_data (sec)->this_hdr.contents = contents; symtab_hdr->contents = (unsigned char *) isymbuf; Those lines of code also appear before the only other call to elf32_avr_relax_delete_bytes() within elf32-avr.c. These lines are missing before the call to elf32_avr_relax_delete_bytes() where the crash happens, and I believe that is the source of the problem. I placed those assignments within the if (deleting_ret_is_safe) block before the call to elf32_avr_relax_delete_bytes() and that fixes the problem. Here is a proposed patch diff -Nur binutils-2.19-orig/bfd/elf32-avr.c binutils-2.19/bfd/elf32-avr.c --- binutils-2.19-orig/bfd/elf32-avr.c 2009-02-14 12:54:24.0 -0500 +++ binutils-2.19/bfd/elf32-avr.c 2009-02-14 13:06:49.0 -0500 @@ -2252,6 +2252,12 @@ "at address 0x%x deleted.\n", (int) dot + insn_size); + /* Note that we've changed the relocs, +section contents, etc. */ + elf_section_data (sec)->relocs = internal_relocs; + elf_section_data (sec)->this_hdr.contents = contents; + symtab_hdr->contents = (unsigned char *) isymbuf; + /* Delete two bytes of data. */ if (!elf32_avr_relax_delete_bytes (abfd, sec, irel->r_offset + insn_size, 2)) -- http://sourceware.org/bugzilla/show_bug.cgi?id=9841 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
