[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #15 from Nick Alcock --- The real question is where the -L/usr/lib is coming from. If you dig into config.status it should become clear. I bet this is derived from some .la file somewhere, so that libtool thinks it needs -L/usr/lib -lfoo to get at libfoo, and this causes trouble for everything else later in the link line. Including syslibdirs in libtool .la files like that is generally considered to be a problem with the local system's setup (though because libtool has no real way to work around it or stop it from happening, it is depressingly common). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #16 from Toolybird --- $ grep "/usr/lib " libctf/config.status sys_lib_search_path_spec='/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0 /usr/lib /lib ' sys_lib_dlsearch_path_spec='/lib /usr/lib /usr/lib/libfakeroot ' That looks fairly normal to me. The only .la files involved in the relink are libctf.la and ../bfd/libbfd.la. They both contain a line: libdir='/usr/lib' (Incidentally, libctf.la also has `-rpath /usr/lib' in the relink_command section, though I don't think that's relevant.) Once the .la files are "substituted" for the real relink command, it seems the -L/usr/lib is caused by ../bfd/libbfd.la In trying to debug this I jammed a "set -x" into libtool and yeah, well, my brain still hurts.. In summary, the current code is incorrect in the `--prefix=/usr --enable-shared' case due to the libtool relink. If you were to revert the bits that cause the relink, everything should go back to hunky-dory. In the original commit message you mentioned "a libtool bug which as far as I can see is no longer present". Unfortunately I think the libtool bug is still there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27722] New: ld/libdep_plugin.c:142:19: error: array subscript has type ‘char’ [-Werror=char-subscripts]
https://sourceware.org/bugzilla/show_bug.cgi?id=27722 Bug ID: 27722 Summary: ld/libdep_plugin.c:142:19: error: array subscript has type ‘char’ [-Werror=char-subscripts] Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: sdanyyil at yahoo dot com Target Milestone: --- I have to add #pragma GCC diagnostic warning "-Wuninitialized" to the file for gcc to compile it. Error Message: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../ld -I. -I../../ld -I../bfd -I../../ld/../bfd -I../../ld/../include -I../../ld/../zlib -I./../intl -g -O2 -DLOCALEDIR=\"/usr/local/share/locale\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -DELF_LIST_OPTIONS=false -DELF_SHLIB_LIST_OPTIONS=false -DELF_PLT_UNWIND_LIST_OPTIONS=false -g -O2 -MT libdep_plugin.lo -MD -MP -MF .deps/libdep_plugin.Tpo -c ../../ld/libdep_plugin.c -o libdep_plugin.o In file included from ../../ld/libdep_plugin.c:26: ../../ld/libdep_plugin.c: In function ‘str2vec’: ../../ld/libdep_plugin.c:142:19: error: array subscript has type ‘char’ [-Werror=char-subscripts] 142 | while (isspace (*s)) s++; | ^~ ../../ld/libdep_plugin.c:166:20: error: array subscript has type ‘char’ [-Werror=char-subscripts] 166 | if (isspace (*s)) |^~ ../../ld/libdep_plugin.c:171:20: error: array subscript has type ‘char’ [-Werror=char-subscripts] 171 |while (isspace (*s)) s++; |^~ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 John Dong changed: What|Removed |Added CC||dongjianqiang2 at huawei dot com --- Comment #22 from John Dong --- (In reply to cvs-com...@gcc.gnu.org from comment #21) > The binutils-2_36-branch branch has been updated by Alan Modra > : > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=d3edaa91d4cf7202ec14342410194841e2f67f12 > > commit d3edaa91d4cf7202ec14342410194841e2f67f12 > Author: Alan Modra > Date: Fri Feb 26 11:30:32 2021 +1030 > > Reinstate various pieces backed out from smart_rename changes > > In the interests of a stable release various last minute smart_rename > patches were backed out of the 2.36 branch. The main reason to > reinstate some of those backed out changes here is to make necessary > followup fixes to commit 8e03235147a9 simple cherry-picks from > mainline. A secondary reason is that ar -M support isn't fixed for > pr26945 without this patch. > > PR 26945 > * ar.c: Don't include libbfd.h. > (write_archive): Replace xmalloc+strcpy with xstrdup. > * arsup.c (temp_name, real_ofd): New static variables. > (ar_open): Use make_tempname and bfd_fdopenw. > (ar_save): Adjust to suit ar_open changes. > * objcopy.c: Don't include libbfd.h. > * rename.c: Rename and reorder variables. > > (cherry picked from commit 95b91a043aeaeb546d2fea556d84a2de1e917770) Hi, can we backport this patch to binutils-2_34-branch ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27722] ld/libdep_plugin.c:142:19: error: array subscript has type ‘char’ [-Werror=char-subscripts]
https://sourceware.org/bugzilla/show_bug.cgi?id=27722 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1cfc6f00e45104551da9146bb413b60acd0e387f commit 1cfc6f00e45104551da9146bb413b60acd0e387f Author: Alan Modra Date: Tue Apr 13 16:00:10 2021 +0930 PR27722, error: array subscript has type char PR 27722 * libdep_plugin.c (str2vec): Don't pass a potentially signed char to isspace. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #23 from Alan Modra --- (In reply to John Dong from comment #22) > Hi, can we backport this patch to binutils-2_34-branch ? You can of course do what you like with your own copy of binutils, but I don't consider this series of patches appropriate for backporting to earlier FSF binutils branches. -- You are receiving this mail because: You are on the CC list for the bug.
