[Bug ld/19526] Using "gcc -o /dev/null" gives "ld: final link failed: File truncated" error
https://sourceware.org/bugzilla/show_bug.cgi?id=19526 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED CC||danglin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #12 from John David Anglin --- Fixed on trunk by commit 6d4b286. -- 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/19541] Format reader for ILF format (used by MSVC-generated import libraries) does not properly handle data imports
https://sourceware.org/bugzilla/show_bug.cgi?id=19541
--- Comment #3 from Nathaniel J. Smith ---
Created attachment 8946
--> https://sourceware.org/bugzilla/attachment.cgi?id=8946=edit
Tiny ILF file with DATA symbol for testing
Attaching an example ILF-format import member, extracted from a 32-bit
python27.lib (as created by MSVC, and distributed in the python.org official
python 2.7 windows downloads).
Without the patch, nm on this file shows no symbols; after the patch, it
correctly shows a reference to __imp___Py_NoneStruct. Also, here's a simple
test case:
nonestruct-test.c
__declspec(dllimport) struct PyObject_Struct _Py_NoneStruct;
struct PyObject_Struct *f()
{
return &_Py_NoneStruct;
}
end nonestruct-test.c
Without the patch, linking this program to export-_Py_NoneStruct.o fails with:
undefined reference to `_imp___Py_NoneStruct'
but with the patch, linking succeeds and correctly creates an import table
referencing _Py_NoneStruct.
--
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/19520] [2.26 regression] R_386_GOT32X relocation breaks gcc bootstrap with non-gld/gold linker
https://sourceware.org/bugzilla/show_bug.cgi?id=19520 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #10 from H.J. Lu --- I am waiting for confirmation before applying it to master and backporting to 2.26 branch. -- 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/19541] Format reader for ILF format (used by MSVC-generated import libraries) does not properly handle data imports
https://sourceware.org/bugzilla/show_bug.cgi?id=19541 --- Comment #2 from Nathaniel J. Smith --- Update: on further investigation my helpful tester reports that their segfault problem was an unrelated configuration error that they made; once they sorted that out then all was well. So, I'm now fairly confident that the attached patch does in fact solve the problem. -- 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
Re:binutils-2.26 configure doesn't fall back to 'ar' if it can't find 'x86_64-unknown-linux-gnu-ar'
I'm currently configuring binutils with:
./configure \
--prefix="${_toolroot}" \
--host="${_local_triplet}" \
--target="${_target_triplet}" \
--with-sysroot="${_sysroot}" \
--disable-nls --disable-multilib \
--disable-static --disable-werror \
--with-lib-path="${_toolroot}/lib"
which works fine for 2.25. In this case,
_local_triplet="x86_64-unknown-linux-gnu", while
_target_triplet="mips-linux-musl".
It's also fairly similar to how CLFS does it
(http://clfs.org/view/CLFS-3.0.0-SYSTEMD/mips/cross-tools/binutils.html), so it
*should* be about right?
In any case, it appears that the 2.25 configure script detected the build
system as 'x86_64-unknown-linux-gnu', while the 2.26 configure script detects
the build system as 'x86_64-pc-linux-gnu'. Thanks for the hint!
This was changed by upstream:
http://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=ca9bfb8cc75a2be1819d89c664a867785c96c9ba;hp=1c8b09aec7b36055f10c59c587a13a9828091492
and then merged:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=5960642af99c6dc84b28e1bc69a617099b9dee97
Relevant mailing list thread:
http://lists.gnu.org/archive/html/config-patches/2015-06/msg00013.html
So it appears that I either need to add --build, or I need to change the host
triplet to x86_64-pc-linux-gnu? Which would be better?
I assume that this not a bug (just a configuration issue on my part).
Alastair Hughes
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19542] Preformance penalty when linking chromium executable
https://sourceware.org/bugzilla/show_bug.cgi?id=19542 --- Comment #7 from Markus Trippelsdorf --- > 3. Show us where time is spent in linker. Can you please "perf record" the linker invocation for some minutes and then post the "perf report" output here. -- 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/19542] Preformance penalty when linking chromium executable
https://sourceware.org/bugzilla/show_bug.cgi?id=19542 --- Comment #6 from Armin K. --- Created attachment 8945 --> https://sourceware.org/bugzilla/attachment.cgi?id=8945=edit Marked ps aux output The attached file is actually ps aux output containing clang++ and ld invocation command lines. You can examine the file to find the "CPU time" field, which is in the captured file at 30 minutes running (which was equivalent to the real time that was spent running the ld executable). After capturing the output, it has been running for at least 15 more minutes. I was watching in htop, and the time field was updating just like the real time, so it's as good metric as any other. -- 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/19542] New: Preformance penalty when linking chromium executable
https://sourceware.org/bugzilla/show_bug.cgi?id=19542 Bug ID: 19542 Summary: Preformance penalty when linking chromium executable Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: krejzi at email dot com Target Milestone: --- Created attachment 8944 --> https://sourceware.org/bugzilla/attachment.cgi?id=8944=edit compiler and linker command line When linking chromium executable, the link process now takes insane amount of time with binutils-2.26. Previously, with binutils-2.25.x series, it would take no longer than 5 minutes. With binutils 2.26, it takes more than 40 minutes of hogging the CPU to produce the same executable. The file containing information about compiler and linker invocation is attached. I am not sure if any of the parameters causes the issue. -- 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/19542] Preformance penalty when linking chromium executable
https://sourceware.org/bugzilla/show_bug.cgi?id=19542 --- Comment #3 from Armin K. --- (In reply to Markus Trippelsdorf from comment #1) > This happens when using ld.bfd, right? > > You could try ld.gold instead. It links chromium in a few seconds on my > machine. Yes ld.bfd. I had a couple of issues when using ld.gold in the past. I could try it again though. -- 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
Re: binutils-2.26 configure doesn't fall back to 'ar' if it can't find 'x86_64-unknown-linux-gnu-ar'
You didn't tell how you ran configure. That usually happens if it thinks that you are building with a cross compiler. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19542] Preformance penalty when linking chromium executable
https://sourceware.org/bugzilla/show_bug.cgi?id=19542 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot de --- Comment #1 from Markus Trippelsdorf --- This happens when using ld.bfd, right? You could try ld.gold instead. It links chromium in a few seconds on my machine. -- 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/19542] Preformance penalty when linking chromium executable
https://sourceware.org/bugzilla/show_bug.cgi?id=19542 --- Comment #2 from Markus Trippelsdorf --- Also make sure you have enough RAM and your system is not swapping. -- 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/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #14 from poma --- (In reply to H.J. Lu from comment #9) > Created attachment 8941 [details] > Please try this simpler patch With this patch build finishes, but produced binaries break extlinux/isolinux loading. Thanks for trying. -- 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
binutils-2.26 configure doesn't fall back to 'ar' if it can't find 'x86_64-unknown-linux-gnu-ar'
I've tried updating to binutils 2.26, however, it currently fails to build as it tries to use "x86_64-unknown-linux-gnu-ar". The old configure script (binutils 2.25) noticed that various x86_64-unknown-linux-gnu-* tools did not exist, and instead falls back to plain 'ar' (or readelf, or ld, or...), while the configure script for binutils 2.26 tries to use the x86_64-unknown-linux-gnu-* names anyway. I can't see anything in the git log that would cause this change - what have I missed? Is this a regression? I've rebuilt 2.25 on my system to check that it was a binutils problem, and can attach the logs from both builds if that would help. Regards, Alastair Hughes ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/19520] [2.26 regression] R_386_GOT32X relocation breaks gcc bootstrap with non-gld/gold linker
https://sourceware.org/bugzilla/show_bug.cgi?id=19520 Richard PALO changed: What|Removed |Added CC||richard at netbsd dot org --- Comment #9 from Richard PALO --- Unfortunately this patch branch is not based upon 2.26.0 (as in the source tarball) so a format-patch output does not patch cleanly for distributions. Will/can 2.26.1 be quickly released? -- 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/19542] Preformance penalty when linking chromium executable
https://sourceware.org/bugzilla/show_bug.cgi?id=19542 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from H.J. Lu --- Please 1. Provide a small testcase to show 8X slowdown. Or 2. Provide ALL linker inputs. Or 3. Show us where time is spent in linker. -- 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/19542] Preformance penalty when linking chromium executable
https://sourceware.org/bugzilla/show_bug.cgi?id=19542 H.J. Lu changed: What|Removed |Added CC||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
