Created attachment 14644 [details] test case $ ld -melf_i386 -shared --whole-archive libc.a (libc.a is from attachment) This generates many "undefined reference" errors, which is weird with "-shared" and cannot be suppressed with "-z undefs" or any other options. Both lld and gold produce the right message: "ld.lld: error: libc.a(acos.O): not an ELF file"
Hi Stas, I think that this problem has already been fixed: % ld-new -melf_i386 -shared --whole-archive libc.a ld-new: libc.a: member libc.a(acos.O) in archive is not an object % ld-new -melf_i386 -shared --whole-archive libc.a --version GNU ld (GNU Binutils) 2.40.50.20230131 In fact I think that it has been fixed for a while now. I tested as far back as 2.37 and it is fixed there. However - it does look like it might be a distribution specific problem. I checked Fedora rawhide (which uses binutils 2.39), and that certainly does produce the errors: % ld -melf_i386 -shared --whole-archive libc.a ld: libc.a(acos.O):fake:(.text+0x49): undefined reference to `_errno' [...] % ld --version GNU ld version 2.39-9.fc38 So I suggest that you refile this bug with whichever distribution you are using. Cheers Nick
Thanks! May I guess that the fix went to the older branches as a back-port, but wasn't initially in them? Do you know in what version it initially went in, not as a back-port? Or maybe you know the exact commit that I should ask the distro to apply? If you don't have such info, then feel free to close. This bug is not urgent (its only about a bad diagnostic), so if there is no concrete patch to back-port, then I'll live without it quite well. :)
(In reply to Stas Sergeev from comment #2) > May I guess that the fix went to the older branches as a > back-port, but wasn't initially in them? Possibly - or ... it could be that it was never a bug in the upstream binutils sources, but rather a bug that was introduced by the patches that distribution maintainers apply on top of the stock sources. > Do you know in what version it initially went in, not as a back-port? Sorry no. I checked as far back as 2.37, but I do not have earlier releases to hand. (I could get them, but it would be a hassle). > Or maybe you know the exact commit that I should ask the distro > to apply? Given that, for example, the bug is not present when running a linker built from the upstream 2.39 binutils sources, but it is present when running the Fedora rawhide linker (which is 2.39 + local patches), I would say that it is unlikely that a commit is missing from the sources. > If you don't have such info, then feel free to close. > This bug is not urgent (its only about a bad diagnostic), so if > there is no concrete patch to back-port, then I'll live without > it quite well. :) OK, well I am going to close this PR, but do feel free to raise it with whichever distribution you use. Cheers Nick
Your @redhat address indicates you may well raise it to fedora? :)
(In reply to Stas Sergeev from comment #4) > Your @redhat address indicates you may well raise it to fedora? :) I could... but I am hoping that you file the bug report yourself (since you care about it). You can do so here: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora This will then get through to the Fedora binutils maintainer, who is ... me! But - it will be on a different bug-reporting system, and it will indicate that this is a Fedora specific problem and not a GNU Binutils problem.
The input files are i386 COFF files. If the linker supports i386 COFF, you will get the undefined symbol error for i386 COFF input: (gdb) bt #0 undefined_symbol (info=0x655da0 <link_info>, name=0x689a40 "_errno", abfd=0x688ae0, section=0x68b038, address=73, error=true) at /export/gnu/import/git/sources/binutils-gdb/ld/ldmain.c:1425 #1 0x000000000045cc39 in bfd_generic_get_relocated_section_contents ( abfd=0x6771e0, link_info=0x655da0 <link_info>, link_order=<optimized out>, data=<optimized out>, relocatable=false, symbols=<optimized out>) at /export/gnu/import/git/sources/binutils-gdb/bfd/reloc.c:8452 #2 0x0000000000457084 in default_indirect_link_order (output_bfd=0x6771e0, info=0x655da0 <link_info>, output_section=0x6783a0, link_order=0x687e28, generic_linker=generic_linker@entry=false) at /export/gnu/import/git/sources/binutils-gdb/bfd/linker.c:2656 #3 0x0000000000458f76 in _bfd_default_link_order (abfd=abfd@entry=0x6771e0, info=info@entry=0x655da0 <link_info>, sec=sec@entry=0x6783a0, link_order=link_order@entry=0x687e28) at /export/gnu/import/git/sources/binutils-gdb/bfd/linker.c:2475 #4 0x000000000049ce06 in bfd_elf_final_link (abfd=<optimized out>, info=<optimized out>) at /export/gnu/import/git/sources/binutils-gdb/bfd/elflink.c:12801 #5 0x000000000041cab9 in ldwrite () at /export/gnu/import/git/sources/binutils-gdb/ld/ldwrite.c:545 #6 0x0000000000404a86 in main (argc=<optimized out>, argv=<optimized out>) at /export/gnu/import/git/sources/binutils-gdb/ld/ldmain.c:531 (gdb)
(In reply to H.J. Lu from comment #6) > The input files are i386 COFF files. If the linker supports i386 COFF, you > will > get the undefined symbol error for i386 COFF input: Thanks for an update. But I explicitly said "-melf_i386", so is it good to try to "support COFF" here? Also those undefined symbols are weird for -shared and unsuppressible by any option. So is it still a bug then?
So re-opening per HJ's update. Obviously its not fixed, just depends on a build options.
No, there isn't a bug here that needs fixing. Linking input object files to other output formats is something that ld can do in only very limited circumstances and certainly not in the case you are trying. I believe it was a design goal for BFD a very long time ago, but one that proved impractical.
(In reply to Alan Modra from comment #9) > No, there isn't a bug here that needs fixing. Linking input object files to > other output formats is something that ld can do in only very limited > circumstances and certainly not in the case you are trying. But there was no asking of that. I only wanted an adequate error message.
Sorry, but it isn't an error to try to link a foreign input file.