[Bug libsframe/30014] FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe
https://sourceware.org/bugzilla/show_bug.cgi?id=30014 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The binutils-2_40-branch branch has been updated by Indu Bhagat : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bcea253f5fa194e57f9564e8461c718e228bd26e commit bcea253f5fa194e57f9564e8461c718e228bd26e Author: Indu Bhagat Date: Wed Jan 18 23:17:49 2023 -0800 toplevel: Makefile.def: add install-strip dependency on libsframe As noted in PR libsframe/30014 - FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe, the install time dependencies of libbfd need to be updated. PR libsframe/30014 * Makefile.def: Reflect that libsframe needs to installed before libbfd. Reorder a bit to better track libsframe dependencies. * Makefile.in: Regenerate. (cherry picked from commit b8d21eb0cd10d6127e77cc437d82e949adb0c454) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libsframe/30014] FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe
https://sourceware.org/bugzilla/show_bug.cgi?id=30014 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Indu Bhagat : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b8d21eb0cd10d6127e77cc437d82e949adb0c454 commit b8d21eb0cd10d6127e77cc437d82e949adb0c454 Author: Indu Bhagat Date: Wed Jan 18 23:17:49 2023 -0800 toplevel: Makefile.def: add install-strip dependency on libsframe As noted in PR libsframe/30014 - FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe, the install time dependencies of libbfd need to be updated. PR libsframe/30014 * Makefile.def: Reflect that libsframe needs to installed before libbfd. Reorder a bit to better track libsframe dependencies. * Makefile.in: Regenerate. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libsframe/30014] FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe
https://sourceware.org/bugzilla/show_bug.cgi?id=30014 Indu Bhagat changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-19 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30022] concurrent builds can fail
https://sourceware.org/bugzilla/show_bug.cgi?id=30022 Sam James changed: What|Removed |Added CC||sam at gentoo dot org --- Comment #1 from Sam James --- Can you send the patch to the gdb-patches mailing list? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29987] bfd/archive.c:1447: undefined reference to `filename_ncmp'
https://sourceware.org/bugzilla/show_bug.cgi?id=29987 --- Comment #7 from Jan-Benedict Glaw --- Build is currently restored by reverting the initial patch. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 55037 in oss-fuzz: binutils:fuzz_as: Null-dereference READ in strcasecmp
Updates: Labels: -restrict-view-commit Comment #3 on issue 55037 by sheriffbot: binutils:fuzz_as: Null-dereference READ in strcasecmp https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55037#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/30022] New: concurrent builds can fail
https://sourceware.org/bugzilla/show_bug.cgi?id=30022 Bug ID: 30022 Summary: concurrent builds can fail Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: vincent.vsmeets at gmail dot com Target Milestone: --- Created attachment 14606 --> https://sourceware.org/bugzilla/attachment.cgi?id=14606=edit Patch for */Makefile.am Hello, during building of the debian package binutils-m68hc1x, I noticed that building the package with a 16 core cpu can lead to build errors. The build log shows the following output: === PASS: test-strtol-18. PASS: test-strtol-19. PASS: test-strtol-20. libtooldir=`/bin/bash ./libtool --config | /bin/sed -n -e 's/^objdir=//p'`; \ if [ -f $libtooldir/libbfd.a ]; then \ cp $libtooldir/libbfd.a libbfd.tmp; \ ranlib --plugin /usr/lib/gcc/x86_64-linux-gnu/12/liblto_plugin.so libbfd.tmp; \ /bin/bash ../../src/bfd/../move-if-change libbfd.tmp libbfd.a; \ else true; fi ranlib: 'libbfd.tmp': No such file cmp: libbfd.tmp: No such file or directory mv: cannot stat 'libbfd.tmp': No such file or directory ./test-expandargv cmp: libbfd.tmp: No such file or directory make[5]: *** [Makefile:3086: stamp-lib] Error 2 make[5]: Leaving directory '/<>/obj-x86_64-linux-gnu/bfd' make[4]: *** [Makefile:2100: all-recursive] Error 1 make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu/bfd' make[3]: *** [Makefile:1477: all] Error 2 make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu/bfd' ./test-demangle < ../../../src/libiberty/testsuite/demangle-expected make[2]: *** [Makefile:3075: all-bfd] Error 2 make[2]: *** Waiting for unfinished jobs ./test-demangle < ../../../src/libiberty/testsuite/d-demangle-expected PASS: test-expandargv-0. PASS: test-expandargv-1. === What happens is that "libbfd.a" is copied to "libbfd.tmp". "libbfd.tmp" is then possibly modified and in case it has been changed, then copied back to "libbfd.a". In the log file, I see that this make-target is executed multiple times. This normally works fine, but in this case, two threads copy the "libbfd.a" file to "libbfd.tmp" at almost the same time. Then one thread continues and moves the file back to "libbfd.a". The file "libbfd.tmp" is then removed by that thread. After that, the other thread wants to execute the same statements, but can't find the file "libbfd.tmp" anymore (because it has been deleted by the first thread). This leads to the errors as shown above. I have attached a patch to this bug report. My solution is to not use a static temporary filename like "libbfd.tmp", but a unique filename created by the command "mktemp". That way, every thread uses it's own temporary file. Regards, Vincent -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30022] concurrent builds can fail
https://sourceware.org/bugzilla/show_bug.cgi?id=30022 Vincent Smeets changed: What|Removed |Added CC||vincent.vsmeets at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=29998 --- Comment #10 from Jan Janssen --- > So possibly s->output_section is not a valid pointer ? Mind you this does > seem unlikely as that very same indirection has been used in several places > before line 1538. To be honest though, I have never really trusted the line > numbers displayed in stack backtraces... Probably, you were looking at the wrong sources (mingw-w64-binutils is on 2.38 on arch). I just now decided to take the arch PKGBUILD and update it to 2.40 and it still crashes. My debugger shows me this in pe-dll.c@1544: bfd_vma sec_vma = s->output_section->vma + s->output_offset; Here are some variable values of interest: s->output_section == NULL (which causes the SIGSEGV) s->output_offset == 0 s->section == ".text" b->filename == "_chkstk_ms.o" Lemme know if you need more info (or want me to test a patch). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #9 from Frank Ch. Eigler --- > Yes - I am afraid that the watermark protocol document is a bit out of date, > and its rules for note merging do need to be updated. I'd suggest not over-specifying merging, or specifying merging per se at all. How about only documenting the semantics of the notes for consumers? Any transform that preserves those semantics would be fine. > [...] > With this patch applied I found that merging libxul.so went down from 10.5 > minutes to 5 minutes on my local machine. Not an order of magnitude > improvement I know, but would it be enough for you ? Nice improvement. I'm not in a position to set a goal. I can only suspect that it could be gotten down to a few seconds instead of a few minutes, but dunno whether there are hard constraints. > I am hesitant to rewrite the algorithm entirely because if I get it wrong I > am likely to break the building of other packages - either by corrupting the > notes so that annocheck then complains, or breaking the merge process so > that the rpms do not build or something else. Understood - that comes from being in the honoured place deep within the buildroot. :-) OTOH, it should be possible to mass-build a variety of packages, run a new merger, and test it against some older and more current annocheck consumers, to confirm no change. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29521] [docs] man pages are not in the release tarball
https://sourceware.org/bugzilla/show_bug.cgi?id=29521 Kurt Goebel changed: What|Removed |Added Priority|P3 |P2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26236] ld on sparc produces R_SPARC_NONE relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=26236 Sam James changed: What|Removed |Added See Also|https://sourceware.org/bugz | |illa/show_bug.cgi?id=23732 | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=29998 --- Comment #9 from Nick Clifton --- Hi Jan, Dang - I still cannot reproduce this problem. The issue now is that I have the wrong version of the compiler installed on my system (an x86_64 box running Fedora 36): lto1: fatal error: bytecode stream in file 'test2.obj' generated with LTO version 12.0 instead of the expected 11.2 compilation terminated. The generate_reloc() function is quite complex, so it is not so surprising that there might be a problem in it. If you are able to rebuild the linker, would you mind adding some printf() statements around the problematic line (pe-dll.c:1538) ? Looking at the sources I have, this is: if (s->output_section->vma == 0) So possibly s->output_section is not a valid pointer ? Mind you this does seem unlikely as that very same indirection has been used in several places before line 1538. To be honest though, I have never really trusted the line numbers displayed in stack backtraces... Sorry I cannot be of much help. but without the ability to reproduce the problem I cannot investigate it. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=94e76498c3790d90c383621b88268abf9acdd5bf commit 94e76498c3790d90c383621b88268abf9acdd5bf Author: Nick Clifton Date: Wed Jan 18 11:32:21 2023 + Speed up objcopy's note merging. PR 29993 * objcopy.c (merge_gnu_build_notes): Remember the last non-deleted note in order to speed up the scan for matching notes. -- You are receiving this mail because: You are on the CC list for the bug.
