[Bug ld/23388] New: [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 Bug ID: 23388 Summary: [2.31 Regression] produces large 64-bit multilib libraries on i386 Product: binutils Version: 2.31 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: doko at debian dot org Target Milestone: --- [ forwarded from https://bugs.debian.org/903376 ] This is seen at least when building x86_64 and x86_64-gnux32 libraries on i686-linux-gnu: > Package: libc6-amd64 > Version: 2.27-4 > Severity: important > > On i386, libc6-amd64 and libc6-x32 install more than one gigabyte each: > > , > | $ apt-cache show libc6-amd64 libc6-x32 | grep Installed-Size > | Installed-Size: 1143839 > | Installed-Size: 1143407 > ` > > Looking at /lib64, all the .so files from libc6-amd64 are over four > megs, although file(1) reports them as stripped. Looks like that is a binutils bug, I see the same problem when building the ncurses multilib packages. Apparently this started when I upgraded binutils from 2.30-22 to 2.30.90.20180627-1. These libraries have a large number of null bytes in them, their occupied space is reduced considerably in a sparse copy: -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 Matthias Klose changed: What|Removed |Added Target||x86_64-linux-gnu, ||x86_64-linux-gnux32 CC||hjl at sourceware dot org Host||i686-linux-gnu -- 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 binutils/23389] New: Have objdump and addr2line retrieve symbols from separate debuginfo files
https://sourceware.org/bugzilla/show_bug.cgi?id=23389 Bug ID: 23389 Summary: Have objdump and addr2line retrieve symbols from separate debuginfo files Product: binutils Version: 2.32 (HEAD) Status: NEW Severity: enhancement Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nickc at redhat dot com Target Milestone: 2.32 When disassembling code, objdump does not retrieve symbols from separate debuginfo files. This leads to less useful when compared to gdb. For example: $ objdump -d --reloc /bin/omping | grep -9 401820: 4017f8: e9 9e fd ff ff jmpq 40159b 4017fd: 48 8d 35 dc a5 00 00lea0xa5dc(%rip),%rsi $ gdb /bin/omping … (gdb) disassemble 0x401820 Dump of assembler code for function _start: 0x00401820 <+0>: xor%ebp,%ebp 0x00401822 <+2>: mov%rdx,%r9 Addr2line has a similar restriction in that it too does not follow links to separate debuginfo files. -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Matthias, Is this because -z separate-code-page is now enabled by default ? (For Linux binaries). If so, I am not sure if this should be considered a real problem, since it: a) helps improve security b) can be disabled from the linker command line c) the default can be changed when the linker is configured d) on sparse filesystems the extra nul bytes do not occupy any real space. Cheers Nick -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 --- Comment #2 from Matthias Klose --- I'm wondering why this is only seen for the non-default multilibs on i686-linux-gnu. -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 --- Comment #3 from H.J. Lu --- I can't reproduce it. With glibc 2.28, I got [hjl@gnu-skx-1 tools-build]$ du -sh glibc/release glibc-x32/release glibc-32bit/release 141Mglibc/release 120Mglibc-x32/release 114Mglibc-32bit/release [hjl@gnu-skx-1 tools-build]$ with debug info. Please show the output of "readelf -lW" on x86-64 libc.so. -- 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/23372] Empty GNU_PROPERTY_X86_ISA_1_NEEDED/GNU_PROPERTY_X86_ISA_1_USED aren't removed
https://sourceware.org/bugzilla/show_bug.cgi?id=23372 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The binutils-2_31-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f6becb01a7532bc0263ad9e0c9e59975c38db269 commit f6becb01a7532bc0263ad9e0c9e59975c38db269 Author: H.J. Lu Date: Thu Jul 5 09:24:07 2018 -0700 x86: Remove x86 ISA properties with empty bits There is no need to generate x86 ISA properties with empty bits in linker output. bfd/ PR ld/23372 * elfxx-x86.c (_bfd_x86_elf_merge_gnu_properties): Remove x86 ISA properties with empty bits. ld/ PR ld/23372 * testsuite/ld-i386/i386.exp: Run pr23372a and pr23372b. * testsuite/ld-i386/pr23372a.d: New file. * testsuite/ld-i386/pr23372a.s: Likewise. * testsuite/ld-i386/pr23372b.d: Likewise. * testsuite/ld-i386/pr23372b.s: Likewise. * testsuite/ld-i386/pr23372c.s: Likewise. * testsuite/ld-x86-64/pr23372a-x32.d: Likewise. * testsuite/ld-x86-64/pr23372a.d: Likewise. * testsuite/ld-x86-64/pr23372a.s: Likewise. * testsuite/ld-x86-64/pr23372b-x32.d: Likewise. * testsuite/ld-x86-64/pr23372b.d: Likewise. * testsuite/ld-x86-64/pr23372b.s: Likewise. * testsuite/ld-x86-64/pr23372c.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run pr23372a, pr23372a-x32, pr23372b and pr23372b-x32. (cherry picked from commit 56ad703d56ffe5dc55d5e719a6ec41fd6cf9bfbe) -- 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/23372] Empty GNU_PROPERTY_X86_ISA_1_NEEDED/GNU_PROPERTY_X86_ISA_1_USED aren't removed
https://sourceware.org/bugzilla/show_bug.cgi?id=23372 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Version|2.32 (HEAD) |2.31 Resolution|--- |FIXED Target Milestone|--- |2.31 --- Comment #3 from H.J. Lu --- Fixed for 2.31. -- 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 binutils/23389] Have objdump and addr2line retrieve symbols from separate debuginfo files
https://sourceware.org/bugzilla/show_bug.cgi?id=23389 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu --- How separate debuginfo files are encoded in the executable? -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.31 --- Comment #4 from H.J. Lu --- I am working on a fix. -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 --- Comment #5 from Matthias Klose --- on x86_64-linux-gnu: $ ls -l /lib/x86_64-linux-gnu/libc-2.27.so -rwxr-xr-x 1 root root 1808440 Jul 7 16:34 /lib/x86_64-linux-gnu/libc-2.27.so on i686-linux-gnu (x86_64-linux-gnu multilib) $ ls -l /lib64/libc-2.27.so -rwxr-xr-x 1 root root 4528184 Jul 7 16:34 /lib64/libc-2.27.so $ readelf -lW /lib/x86_64-linux-gnu/libc-2.27.so Elf file type is DYN (Shared object file) Entry point 0x22c30 There are 12 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x40 0x0040 0x0040 0x0002a0 0x0002a0 R 0x8 INTERP 0x189170 0x00189170 0x00189170 0x1c 0x1c R 0x10 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x00 0x 0x 0x021038 0x021038 R 0x1000 LOAD 0x022000 0x00022000 0x00022000 0x1451c2 0x1451c2 R E 0x1000 LOAD 0x168000 0x00168000 0x00168000 0x04a2b0 0x04a2b0 R 0x1000 LOAD 0x1b2618 0x001b3618 0x001b3618 0x005248 0x0094c8 RW 0x1000 DYNAMIC0x1b5b80 0x001b6b80 0x001b6b80 0x0001e0 0x0001e0 RW 0x8 NOTE 0x0002e0 0x02e0 0x02e0 0x44 0x44 R 0x4 TLS0x1b2618 0x001b3618 0x001b3618 0x10 0x90 R 0x8 GNU_EH_FRAME 0x18918c 0x0018918c 0x0018918c 0x005ed4 0x005ed4 R 0x4 GNU_STACK 0x00 0x 0x 0x00 0x00 RW 0x10 GNU_RELRO 0x1b2618 0x001b3618 0x001b3618 0x0039e8 0x0039e8 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt 03 .plt .plt.got .text __libc_freeres_fn __libc_thread_freeres_fn 04 .rodata .interp .eh_frame_hdr .eh_frame .gcc_except_table .hash 05 .tdata .init_array __libc_subfreeres __libc_atexit __libc_thread_subfreeres __libc_IO_vtables .data.rel.ro .dynamic .got .got.plt .data .bss 06 .dynamic 07 .note.gnu.build-id .note.ABI-tag 08 .tdata .tbss 09 .eh_frame_hdr 10 11 .tdata .init_array __libc_subfreeres __libc_atexit __libc_thread_subfreeres __libc_IO_vtables .data.rel.ro .dynamic .got $ readelf -lW /lib64/libc-2.27.so Elf file type is DYN (Shared object file) Entry point 0x200c30 There are 12 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x40 0x0040 0x0040 0x0002a0 0x0002a0 R 0x8 INTERP 0x421160 0x00421160 0x00421160 0x1c 0x1c R 0x10 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x00 0x 0x 0x021038 0x021038 R 0x20 LOAD 0x20 0x0020 0x0020 0x1451b2 0x1451b2 R E 0x20 LOAD 0x40 0x0040 0x0040 0x04a2a0 0x04a2a0 R 0x20 LOAD 0x44a618 0x0064a618 0x0064a618 0x005248 0x0094c8 RW 0x20 DYNAMIC0x44db80 0x0064db80 0x0064db80 0x0001e0 0x0001e0 RW 0x8 NOTE 0x0002e0 0x02e0 0x02e0 0x44 0x44 R 0x4 TLS0x44a618 0x0064a618 0x0064a618 0x10 0x90 R 0x8 GNU_EH_FRAME 0x42117c 0x0042117c 0x0042117c 0x005ed4 0x005ed4 R 0x4 GNU_STACK 0x00 0x 0x 0x00 0x00 RW 0x10 GNU_RELRO 0x44a618 0x0064a618 0x0064a618 0x0039e8 0x0039e8 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt 03 .plt .plt.got .text __libc_freeres_fn __libc_thread_freeres_fn 04 .rodata .interp .eh_frame_hdr .eh_frame .gcc_except_table .hash 05 .tdata .init_array __libc_subfreeres __libc_atexit __libc_thread_subfreeres __libc_IO_vtables .data.rel.ro .dynamic .got .got.plt .data .bss 06 .dynamic 07 .note.gnu.build-id .note.ABI-tag 08 .tdata .tbss 09 .eh_frame_hdr 10 11 .tdata .init_array __libc_subfreeres __libc_atexit __libc_thread_subfreeres __libc_IO_vtables .data.rel.ro .dynamic .got -- 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/list
[Bug ld/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=872899f1efeda1e93ed569d322c6b2ee85ce885c commit 872899f1efeda1e93ed569d322c6b2ee85ce885c Author: H.J. Lu Date: Mon Jul 9 06:51:17 2018 -0700 bfd: Use changequote for "i[3-7]86-*-linux-*" Use changequote to match "i[3-7]86-*-linux-*", instead of "i3-786-*-linux-*". PR ld/23388 * configure.ac: Use changequote for "i[3-7]86-*-linux-*". * configure: Regenerated. -- 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/23350] multiple prevailing defs for unused variable in lto mode
https://sourceware.org/bugzilla/show_bug.cgi?id=23350
Martin Liska changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #3 from Martin Liska ---
So still present, shows here:
$ cat main.i
int wrl;
$ cat lib.i
int wrl;
void a() {}
$ gcc -c -flto main.i && gcc -c -flto lib.i && ar rusc lib.a lib.o
$ gcc main.o lib.a lib.a
lto1: fatal error: multiple prevailing defs for ‘a’
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: error:
lto-wrapper failed
collect2: error: ld returned 1 exit status
For:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/8 --enable-ssp --disable-libssp
--disable-libvtv --disable-cet --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-8 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 8.1.1 20180614 [gcc-8-branch revision 261584] (SUSE Linux)
$ ld --version
GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.30.0.20180320-5
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
--
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 binutils/23389] Have objdump and addr2line retrieve symbols from separate debuginfo files
https://sourceware.org/bugzilla/show_bug.cgi?id=23389 --- Comment #2 from Nick Clifton --- (In reply to H.J. Lu from comment #1) > How are separate debuginfo files are encoded in the executable? Ah - there are three different ways 1. In a .gnu.debuglink section 2. In a .gnu.altdebuglink section and 3. Via the DW_AT_GNU_dwo_name, DW_AT_dwo_name, DW_AT_GNU_dwo_id and DW_AT_comp_dir DWARF attributes. There is code in binutils/dwarf.c that handles all three, plus some support in bfd/opncls.c as well. Then there is the problem of locating these files, even given the information from these places. There are lots of places to look and different execution environments can provide different, extra, locations as well. A bit of nightmare really. Cheers Nick -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The binutils-2_31-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fa1b3193c52c319469f688b863d90274d3db4ccf commit fa1b3193c52c319469f688b863d90274d3db4ccf Author: H.J. Lu Date: Mon Jul 9 06:51:17 2018 -0700 bfd: Use changequote for "i[3-7]86-*-linux-*" Use changequote to match "i[3-7]86-*-linux-*", instead of "i3-786-*-linux-*". PR ld/23388 * configure.ac: Use changequote for "i[3-7]86-*-linux-*". * configure: Regenerated. (cherry picked from commit 872899f1efeda1e93ed569d322c6b2ee85ce885c) -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from H.J. Lu --- Fixed for 2.31. -- 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 binutils/23389] Have objdump and addr2line retrieve symbols from separate debuginfo files
https://sourceware.org/bugzilla/show_bug.cgi?id=23389 --- Comment #3 from H.J. Lu --- (In reply to Nick Clifton from comment #2) > (In reply to H.J. Lu from comment #1) > > How are separate debuginfo files are encoded in the executable? > > Ah - there are three different ways > > 1. In a .gnu.debuglink section This should work. > 2. In a .gnu.altdebuglink section I didn't see this one. Does GDB work with this? > and > > 3. Via the DW_AT_GNU_dwo_name, DW_AT_dwo_name, DW_AT_GNU_dwo_id > and DW_AT_comp_dir DWARF attributes. This is PR 22434. -- 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/23388] [2.31 Regression] produces large 64-bit multilib libraries on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=23388 H.J. Lu changed: What|Removed |Added CC|hjl at sourceware dot org |hjl.tools at gmail dot 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/23350] multiple prevailing defs for unused variable in lto mode
https://sourceware.org/bugzilla/show_bug.cgi?id=23350 --- Comment #4 from zenith432 at users dot sourceforge.net --- What difference does it make? This is undefined behavior. It doesn't link -fno-lto either. gcc -c main.i && gcc -c lib.i && ar rusc lib.a lib.o gcc main.o lib.a lib.a /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o: in function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status Find an example where the -fno-lto link succeeds. ld is loading the object files in the libraries because it's searching for main. If I add a main() to lib.i it links successfully with -flto - the 2nd load of lib.a sets the duplicate symbol resolutions to PREEMPTED_IR. The error with -flto is only if main is not found - which is also an error in -fno-lto. -- 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/23350] multiple prevailing defs for unused variable in lto mode
https://sourceware.org/bugzilla/show_bug.cgi?id=23350
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #5 from H.J. Lu ---
(In reply to Martin Liska from comment #3)
> So still present, shows here:
>
> $ cat main.i
> int wrl;
>
> $ cat lib.i
> int wrl;
> void a() {}
>
> $ gcc -c -flto main.i && gcc -c -flto lib.i && ar rusc lib.a lib.o
> $ gcc main.o lib.a lib.a
> lto1: fatal error: multiple prevailing defs for ‘a’
> compilation terminated.
> lto-wrapper: fatal error: gcc returned 1 exit status
> compilation terminated.
> /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
> error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
>
Linker checks lib.a to see if there is a non-COMMON definition for
wrl. But linker never includes lib.o in the final link. What makes
lto1 believe that lib.o is needed?
--
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/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762
Martin Storsjö changed:
What|Removed |Added
CC||martin at martin dot st
--- Comment #15 from Martin Storsjö ---
(In reply to Hannes Domani from comment #12)
> (In reply to Nick Clifton from comment #9)
> > Well I have been wracking my brains for a couple of days now, and I cannot
> > think of a better solution either.
> You first suggested this:
> > This would imply that the placement of the __CTOR_LIST__ symbol in
> > libgcc(_ctors.o) is incorrect,
> So is the definition in libgcc2.c even necessary, isn't it always provided
> by the linker?
It's not normally needed, no. As far as I understand it, I think libgcc just
provides the symbol in case nothing else provides it (maybe for other targets
than mingw).
> On the other hand, I don't know why anyone would want to override
> __CTOR_LIST__ anyways.
This issue originated from trying to use mingw-w64 with lld, llvm's linker
(which basically works like msvc's link.exe with a few additions), and doesn't
provide __CTOR_LIST__ and doesn't use linker scripts at all.
When intending to use that linker, we provide __CTOR_LIST__ within mingw-w64's
crt startup object files. If binutils ld would be able to handle this case
(which the original patch achieves), it would (at a later stage when one could
start requiring binutils >= 2.30) reduce the amount of conditionals and the
fact that we need to know what linker we're going to use, when building
mingw-w64.
If we'd enable this codepath for all cases, we'd fix this issue for binutils
2.30 (but at the same time break all earlier versions).
Other potential ways of handling it would be to extend libgcc's fallback
__CTOR_LIST__ to something like this:
__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *
const void * __CTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *
const void * __DTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".ctors.9"), __used__ , aligned(sizeof(void
* const void * __CTOR_END__ = (void *) 0;
__attribute__ (( __section__ (".dtors.9"), __used__ , aligned(sizeof(void
* const void * __DTOR_END__ = (void *) 0;
However I think that only works if the object file that provides it (in the
case of mingw-w64 for lld, in crt2.o) is linked first, before everything else,
placing __CTOR_LIST__ at the head of the .ctors section. And I don't think
that's fit for libgcc since I guess it's too target specific, and would still
cause breakage for any current libgcc version that doesn't have it.
So given that, I guess reverting the patch is the most sensible thing to do,
and we'll have to start over with other approaches, if we want to unify
matters.
--
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
