[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 --- Comment #7 from Alan Modra --- Created attachment 13192 --> https://sourceware.org/bugzilla/attachment.cgi?id=13192=edit fix This passes a sniff-test and cures both testcases. I'll do a little more testing before committing along with Michael's testcase. Interestingly, gcc-8 and gcc-7 don't trigger this problem. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #6 from Alan Modra --- What's happening here (using Michael's testcase, thanks!) is that inlib1@@LIBFOO is seen as being a definition, triggering if (!add_needed && matched && definition && ((dynsym && h->ref_regular_nonweak) || (old_bfd != NULL && (old_bfd->flags & BFD_PLUGIN) != 0 && bind != STB_WEAK) || (h->ref_dynamic_nonweak && (elf_dyn_lib_class (abfd) & DYN_AS_NEEDED) != 0 && !on_needed_list (elf_dt_name (abfd), htab->needed, NULL to pull in lib1.so. However, inlib1@@LIBFOO is actually overridden by inlib1 from the object file. Without symbol versioning we see inlib1 from lib1.so setting override during the first _bfd_elf_merge_symbol call in add_object_symbols and then this if (override && matched) definition = FALSE; stops the non-versioned inlib1 from being considered a reason to pull in lib1.so. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27254] Wrong operand for SADDR (rl78)
https://sourceware.org/bugzilla/show_bug.cgi?id=27254 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- Hi Egor, Thanks for the bug report. I have checked in your suggested change. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27254] Wrong operand for SADDR (rl78)
https://sourceware.org/bugzilla/show_bug.cgi?id=27254 --- Comment #2 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=34c10233cd204fe5ccafde590294fe20978cb7fa commit 34c10233cd204fe5ccafde590294fe20978cb7fa Author: Egor Vishnyakov Date: Mon Feb 1 16:44:32 2021 + Wrong operand for SADDR (rl78) PR 27254 * elf32-rl78.c (rl78_elf_relocate_section): Fix calculation of offset for the R_RL78_RH_SADDR relocation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 --- Comment #5 from Michael Matz --- (In reply to Michael Matz from comment #4) > (In reply to H.J. Lu from comment #2) > > Please try users/hjl/pr26530/master branch: > > > > https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/ > > master > > Yes, that patch series works, but I think we don't want to revert Alans > patch but > rather fix it :) In particular, because it's crucial that the shared-lib symbol has a version (with unversioned it links fine) I would expect the fix to be somehow involving removing a difference between versioned and unversion symbols, not dealing with the as-needed behaviour of pulling or not pulling in members of static archives. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 --- Comment #4 from Michael Matz --- (In reply to H.J. Lu from comment #2) > Please try users/hjl/pr26530/master branch: > > https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/ > master Yes, that patch series works, but I think we don't want to revert Alans patch but rather fix it :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311
--- Comment #3 from Michael Matz ---
FWIW, it's important that the symbol in question is defined in an indirect
shared lib with a symversion, and defined in an input object file itself. I.e.
this is more self-contained:
% cat lib1.c
void inlib1(void) {}
% cat lib2.c
void inlib2(void) {}
% cat app.c
void inlib1(void) {}
int main()
{
return 0;
}
% cat version.txt
LIBFOO {
*;
};
% gcc -shared -fPIC -o lib1.so lib1.c -Wl,-version-script,version.txt
% gcc -shared -fPIC -o lib2.so lib2.c -Wl,--no-as-needed lib1.so
% gcc -c -flto app.c
% gcc app.o -L. -Wl,-rpath-link,. -l2
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: app.o
(symbol from plugin): undefined reference to symbol 'inlib1@@LIBFOO'
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
./lib1.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/27310] ar changed behavior in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27310 --- Comment #1 from H.J. Lu --- See: https://sourceware.org/pipermail/binutils/2020-December/114650.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-01 CC||hjl.tools at gmail dot com Status|UNCONFIRMED |WAITING --- Comment #2 from H.J. Lu --- Please try users/hjl/pr26530/master branch: https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/master -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 Martin Liska changed: What|Removed |Added CC||amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27309] readelf --debug-dump=info --wide output changes in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27309 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Martin, The change was made so that the output from the binutils readelf would be closer to that of the elfutils readelf. Vis: Old Binutils: <14> DW_AT_name : (indirect string, offset: 0x69): ../sysdeps/x86_64/crti.S 2.36 Binutils: <14> DW_AT_name: (strp) (offset: 0x69): ../sysdeps/x86_64/crti.S Elfutils: name(strp) "../sysdeps/x86_64/crti.S" The change also means that the form name can be deduced from the output. Ie "(strp)" indicates that it was DW_FORM_strp. Likewise "(addr)" is DW_FORM_addr and so on. Readelf has never made any promises regarding the consistency of its output, although I do appreciate that changes like this are annoying when they break scripts that are used to the old format. Can the strace configure script be adapted to cope with both versions of readelf's output ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 --- Comment #1 from Martin Liska --- Important to notice, the symbol /usr/lib64/libsystemd.so.0 defines: readelf -sW /usr/lib64/libsystemd.so.0 | grep sd_booted 296: 00059c8068 FUNCGLOBAL DEFAULT 14 sd_booted@@LIBSYSTEMD_209 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27311] New: ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04
https://sourceware.org/bugzilla/show_bug.cgi?id=27311 Bug ID: 27311 Summary: ld.bfd (symbol from plugin): undefined reference to symbol since b1a92c635c1ec10fd703302ce1fc4ab3a8515a04 Product: binutils Version: 2.36 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: mliska at suse dot cz CC: matz at suse dot de Target Milestone: --- Created attachment 13189 --> https://sourceware.org/bugzilla/attachment.cgi?id=13189=edit reproducer Since the revision, the following does not work: $ gcc x.i -O2 -c -flto && gcc x.o -lfoo -L. /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: x.o (symbol from plugin): undefined reference to symbol 'sd_booted@@LIBSYSTEMD_209' /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/libsystemd.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status while ld.gold is fine: $ gcc x.i -O2 -c -flto && gcc x.o -lfoo -L. -fuse-ld=gold and similarly when -flto is omitted: $ gcc x.i -O2 -c && gcc x.o -lfoo -L. -fuse-ld=gold $ ldd libfoo.so ... libsystemd.so.0 => /usr/lib64/libsystemd.so.0 (0x77e62000) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27309] readelf --debug-dump=info --wide output changes in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27309 Martin Liska changed: What|Removed |Added Version|2.35.1 |2.36 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27310] New: ar changed behavior in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27310 Bug ID: 27310 Summary: ar changed behavior in 2.36 Product: binutils Version: 2.36 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: mliska at suse dot cz CC: hyc at symas dot com Target Milestone: --- The following test-case is reduced from eppic package, since f3016d6ce178b76002edde12c30ebe7f608a8e21 the following fails: $ echo "" | gcc -c -o x.o -x c - && ar curl lib.a x.o ar: x.o: file format not recognized -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27309] readelf --debug-dump=info --wide output changes in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27309 --- Comment #1 from Martin Liska --- > Moreover, I broke a strace configure script. * it broke -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27309] New: readelf --debug-dump=info --wide output changes in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27309 Bug ID: 27309 Summary: readelf --debug-dump=info --wide output changes in 2.36 Product: binutils Version: 2.35.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: mliska at suse dot cz CC: nickc at sourceware dot org Target Milestone: --- After https://sourceware.org/bugzilla/show_bug.cgi?id=26847 the following is printed: $ ./binutils/readelf --debug-dump=info --wide /tmp/sample_struct.o | head -n20 Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length:0x39c (32-bit) Version: 2 Abbrev Offset: 0x0 Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer: (strp) (offset: 0x14c): GNU C17 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9] -m32 -mtune=generic -march=x86-64 -gdwarf-2 -fPIE <10> DW_AT_language: (data1) 12 (ANSI C99) <11> DW_AT_name: (strp) (offset: 0x12d): mpers-m32/sample_struct.c <15> DW_AT_comp_dir: (strp) (offset: 0x89): /home/abuild/rpmbuild/BUILD/strace-5.10 <19> DW_AT_stmt_list : (data4) 0x0 <1><1d>: Abbrev Number: 2 (DW_TAG_base_type) <1e> DW_AT_byte_size : (data1) 1 <1f> DW_AT_encoding: (data1) 8(unsigned char) <20> DW_AT_name: (strp) (offset: 0x56): unsigned char <1><24>: Abbrev Number: 2 (DW_TAG_base_type) <25> DW_AT_byte_size : (data1) 2 <26> DW_AT_encoding: (data1) 7(unsigned) before the revision it printed: Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length:0x39c (32-bit) Version: 2 Abbrev Offset: 0x0 Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer: (indirect string, offset: 0x14c): GNU C17 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9] -m32 -mtune=generic -march=x86-64 -gdwarf-2 -fPIE <10> DW_AT_language: 12 (ANSI C99) <11> DW_AT_name: (indirect string, offset: 0x12d): mpers-m32/sample_struct.c <15> DW_AT_comp_dir: (indirect string, offset: 0x89): /home/abuild/rpmbuild/BUILD/strace-5.10 <19> DW_AT_stmt_list : 0x0 <1><1d>: Abbrev Number: 2 (DW_TAG_base_type) <1e> DW_AT_byte_size : 1 <1f> DW_AT_encoding: 8(unsigned char) <20> DW_AT_name: (indirect string, offset: 0x56): unsigned char <1><24>: Abbrev Number: 2 (DW_TAG_base_type) <25> DW_AT_byte_size : 2 <26> DW_AT_encoding: 7(unsigned) I don't see a point why e.g. "(indirect string, offset: 0x89)" should be replaced with "(strp) (offset: 0x89)" in --wide mode. Moreover, I broke a strace configure script. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27303] gold/testsuite/initpri3. test fails on gold and lld, passes on bfd. Which one is correct?
https://sourceware.org/bugzilla/show_bug.cgi?id=27303 Sergei Trofimovich changed: What|Removed |Added CC||ian at airs dot com Component|admin |gold -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27305] New: relinking libctf during install does not find libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27305 Bug ID: 27305 Summary: relinking libctf during install does not find libbfd Product: binutils Version: 2.36 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: eb at emlix dot com Target Milestone: --- I'm cross-building 2.36 and get this error: libtool: relink: powerpc-unknown-linux-gnu-gcc -shared -fPIC -DPIC .libs/libctf_la-ctf-archive.o .libs/libctf_la-ctf-dump.o .libs/libctf_la-ctf-create.o .libs/libctf_la-ctf-decl.o .libs/libctf_la-ctf-error.o .libs/libctf_la-ctf-hash.o .libs/libctf_la-ctf-labels.o .libs/libctf_la-ctf-dedup.o .libs/libctf_la-ctf-link.o .libs/libctf_la-ctf-lookup.o .libs/libctf_la-ctf-open.o .libs/libctf_la-ctf-sha1.o .libs/libctf_la-ctf-string.o .libs/libctf_la-ctf-subr.o .libs/libctf_la-ctf-types.o .libs/libctf_la-ctf-util.o .libs/libctf_la-ctf-open-bfd.o -L/opt/emlix/test/sysroot/usr/lib -lbfd -L/tmp/e2/build/binutils-target/bfd/../libiberty/pic -L/tmp/e2/build/binutils-target/zlib -L/tmp/e2/build/binutils-target/libctf/../libiberty/pic -liberty -lz -ldl -Wl,--no-copy-dt-needed-entries -Wl,--as-needed -Wl,--build-id -Wl,--version-script=./libctf.ver -Wl,-soname -Wl,libctf.so.0 -o .libs/libctf.so.0.0.0 /opt/emlix/test/lib/gcc/powerpc-unknown-linux-gnu/10.2.0/../../../../powerpc-unknown-linux-gnu/bin/ld: cannot find -lbfd collect2: error: ld returned 1 exit status libtool: install: error: relink `libctf.la' with the above command before installing it Makefile:551: recipe for target 'install-libLTLIBRARIES' failed make[3]: *** [install-libLTLIBRARIES] Error 1 The patch for bug 27250 is applied. The interesting part is also: before that patch it seems to build with "-j1", but breaks with "-j10", and now it reliably breaks every time. The build was configured as: ./configure --build=x86_64-pc-linux-gnu --host=powerpc-unknown-linux-gnu --target=powerpc-unknown-linux-gnu --prefix=/usr --disable-werror --enable-deterministic-archives --disable-static --disable-nls --enable-shared --enable-install-libiberty -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27283] gas for alpha fails to build with gcc 11
https://sourceware.org/bugzilla/show_bug.cgi?id=27283 Serge Belyshev changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Serge Belyshev --- Fixed in HEAD. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27259] ld: Support SHF_LINK_ORDER self-link
https://sourceware.org/bugzilla/show_bug.cgi?id=27259 --- Comment #6 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=49daa38f31404d4f4d94d7654248b62183ec9c15 commit 49daa38f31404d4f4d94d7654248b62183ec9c15 Author: Alan Modra Date: Mon Feb 1 09:56:48 2021 +1030 Re: ld: Add a test for PR ld/27259 * testsuite/ld-elf/pr27259.d: Correct sh_link match. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27283] gas for alpha fails to build with gcc 11
https://sourceware.org/bugzilla/show_bug.cgi?id=27283 --- 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=7bba67ec7ca86401a51c44e3fac15ff63a176b54 commit 7bba67ec7ca86401a51c44e3fac15ff63a176b54 Author: Alan Modra Date: Sun Jan 31 12:02:54 2021 +1030 PR27283 gas for alpha fails to build with gcc 11 PR 27283 * config/tc-alpha.c (insert_operand): Delete dead code. -- You are receiving this mail because: You are on the CC list for the bug.
