[Bug binutils/26301] [2.36 Regression] Incorrect detection of libdebuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=26301 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #4 from Nick Clifton --- Hi H.J. (In reply to H.J. Lu from comment #0) > Which features does binutils need from libdebuginfod? The support was enabled in response to this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1860234 The readelf and objdump utilities can use debuginfod servers to supply debug information when examining binaries. If support for debuginfod has been enabled, of course. > It is quite normal to only have > elfutils-debuginfod-client-0.179-2.fc32.x86_64 Hmmm, but if you are building 32-bit rpms shouldn't you also have elfutils-debuginfod-client-0.179.2-fc32.i686 installed ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26301] [2.36 Regression] Incorrect detection of libdebuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=26301 --- Comment #5 from Nick Clifton --- (In reply to Nick Clifton from comment #4) > > It is quite normal to only have > > elfutils-debuginfod-client-0.179-2.fc32.x86_64 > > Hmmm, but if you are building 32-bit rpms shouldn't you also have > elfutils-debuginfod-client-0.179.2-fc32.i686 installed ? Sorry - I meant "running" not "building"... Hmm, which if correct, means that I need to add a requirement on this package. OK, running a local test... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26268] --gc-sections -u __start_cident inconsistent for -r and non-relocatable links
https://sourceware.org/bugzilla/show_bug.cgi?id=26268
--- Comment #3 from H.J. Lu ---
__start_cident isn't meaningful for -r since the output cident section isn't
the final one. Try "-T keep.t" with
--keep.t--
SECTIONS
{
cident : { KEEP(*(cident)) }
}
--
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26301] [2.36 Regression] Incorrect detection of libdebuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=26301 --- Comment #6 from H.J. Lu --- (In reply to Nick Clifton from comment #5) > (In reply to Nick Clifton from comment #4) > > > > It is quite normal to only have > > > elfutils-debuginfod-client-0.179-2.fc32.x86_64 > > > > Hmmm, but if you are building 32-bit rpms shouldn't you also have > > elfutils-debuginfod-client-0.179.2-fc32.i686 installed ? > > Sorry - I meant "running" not "building"... > > Hmm, which if correct, means that I need to add a requirement on > this package. OK, running a local test... I am not building rpm. I am building 32-bit binutils master branch on Fedora 32/x86-64. It was working before that commit, which fails to check if libdebuginfod.so exists. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26301] [2.36 Regression] Incorrect detection of libdebuginfod
https://sourceware.org/bugzilla/show_bug.cgi?id=26301 --- Comment #7 from Nick Clifton --- Hi H.J. (In reply to H.J. Lu from comment #6) > I am not building rpm. I am building 32-bit binutils master branch > on Fedora 32/x86-64. It was working before that commit, which fails > to check if libdebuginfod.so exists. Sorry - I was in Fedora mode. OK - so you are saying that Aaron's update to debuginfo.m4 broke building the binutils in an environment where the debuginfod header is available but the shared library is not. Got it. In which case I will back off and let Aaron and/or Tom fix it... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26302] New: nm -D -u now by default displays symbol versions, adding --with-symbol-versions duplicates them
https://sourceware.org/bugzilla/show_bug.cgi?id=26302 Bug ID: 26302 Summary: nm -D -u now by default displays symbol versions, adding --with-symbol-versions duplicates them Product: binutils Version: 2.35 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: qbo...@pld-linux.org Target Milestone: --- `nm -D -u` behaviour changed between 2.34 and 2.35. New version prints undefined symbol versions, adding --with-symbol-versions duplicates them. It's probably connected with PR/25708 changes. Example (from linux kernel tools, which build gets broken after binutils upgrade to 2.35 - reported in PLD Linux, Debian and Ubuntu): nm 2.34 (i686-linux): $ nm -u -D plugin_function.so U free U memset U realloc U strcmp U strdup U tep_find_function U tep_get_field_val U tep_plugin_add_options U tep_plugin_remove_options U tep_register_event_handler U tep_unregister_event_handler U trace_seq_printf U trace_seq_putc U warning $ nm -u -D --with-symbol-versions plugin_function.so U free@GLIBC_2.0 U memset@GLIBC_2.0 U realloc@GLIBC_2.0 U strcmp@GLIBC_2.0 U strdup@GLIBC_2.0 U tep_find_function U tep_get_field_val U tep_plugin_add_options U tep_plugin_remove_options U tep_register_event_handler U tep_unregister_event_handler U trace_seq_printf U trace_seq_putc U warning nm 2.35 (x86_64-linux, so symbol versions differ from i686): $ nm -u -D plugin_function.so U free@@GLIBC_2.2.5 U memset@@GLIBC_2.2.5 U realloc@@GLIBC_2.2.5 U strcmp@@GLIBC_2.2.5 U strdup@@GLIBC_2.2.5 U tep_find_function U tep_get_field_val U tep_plugin_add_options U tep_plugin_remove_options U tep_register_event_handler U tep_unregister_event_handler U trace_seq_printf U trace_seq_putc U warning $ nm -u -D --with-symbol-versions plugin_function.so U free@@GLIBC_2.2.5@GLIBC_2.2.5 U memset@@GLIBC_2.2.5@GLIBC_2.2.5 U realloc@@GLIBC_2.2.5@GLIBC_2.2.5 U strcmp@@GLIBC_2.2.5@GLIBC_2.2.5 U strdup@@GLIBC_2.2.5@GLIBC_2.2.5 U tep_find_function U tep_get_field_val U tep_plugin_add_options U tep_plugin_remove_options U tep_register_event_handler U tep_unregister_event_handler U trace_seq_printf U trace_seq_putc U warning The same is visible on any dynamic library, e.g. libc.so.6: $ nm -D -u /lib/libc.so.6 U _dl_argv@@GLIBC_PRIVATE U _dl_exception_create@@GLIBC_PRIVATE U _dl_find_dso_for_object@@GLIBC_PRIVATE [...] $ nm -D -u /lib/libc.so.6 --with-symbol-versions U _dl_argv@@GLIBC_PRIVATE@GLIBC_PRIVATE U _dl_exception_create@@GLIBC_PRIVATE@GLIBC_PRIVATE U _dl_find_dso_for_object@@GLIBC_PRIVATE@GLIBC_PRIVATE -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25155] libctf directory doesn't compile with MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=25155 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Joel Brobecker : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=555adca2e3bcabdef58abf2f68291e47479bc09d commit 555adca2e3bcabdef58abf2f68291e47479bc09d Author: Eli Zaretskii Date: Sun Jul 26 16:06:02 2020 -0700 libctf: compilation failure on MinGW due to missing errno values This commit fixes a compilation failure in a couple of libctf files due to the use of EOVERFLOW and ENOTSUP, which are not defined when compiling on MinGW. libctf/ChangeLog: PR binutils/25155: * ctf-create.c (EOVERFLOW): If not defined by system header, redirect to ERANGE as a poor man's substitute. * ctf-subr.c (ENOTSUP): If not defined, use ENOSYS instead. (cherry picked from commit 50500ecfefd6acc4c7f6c2a95bc0ae1945103220) -- You are receiving this mail because: You are on the CC list for the bug.
