bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/26314] Linking LTO objects with conflicting symbol definitions f


From: cvs-commit at gcc dot gnu.org
Subject: [Bug ld/26314] Linking LTO objects with conflicting symbol definitions from static and shared libraries fails
Date: Fri, 31 Jul 2020 11:01:58 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=26314

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Alan Modra <amodra@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a896df97b952d4f3feed8068eaa70147d12e0e28

commit a896df97b952d4f3feed8068eaa70147d12e0e28
Author: Alan Modra <amodra@gmail.com>
Date:   Fri Jul 31 16:37:17 2020 +0930

    PR26314, Linking LTO objects with symbols from static and shared libraries

    gcc -O2 -g -o ar -Wl,--as-needed arparse.o arlex.o ar.o not-ranlib.o
arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o
libbfd-2.35-3.fc33.so libiberty.a -Wl,-R,.

    All of the above .o files are lto, leading to libbfd-2.35-3.fc33.so
    not being found needed when loading the IR objects.  That's problem
    number one:  We exclude IR references when deciding a shared library
    is needed.  See PR15146.  Thus none of the libbfd.so symbols are
    loaded before libiberty.a is scanned, and libbfd.so contains copies of
    libiberty.a functions.  We ought to be using the libbfd.so copies
    rather than extracting them from the archive (an object is extracted
    even to satisfy IR symbols).  After lto recompilation, libbfd.so is of
    course found to be needed and loaded.  But that causes more problems.
    The lto recompilation didn't see symbol references from libbfd.so and
    variables like _xexit_cleanup are made local in the recompiled
    objects.  Oops, two copies of them.  Finally, those silly undefined
    symbols in the lto output debug files, combined with definitions in
    both libbfd.so and IR objects result in IR symbols being made
    dynamic.

    The main fix here is to revert the PR15146 change to
    elf_link_add_object_symbols.

            PR 26314
            * elflink.c (bfd_elf_link_record_dynamic_symbol): Don't allow
            IR symbols to become dynamic.
            (elf_link_add_object_symbols): Don't exclude IR symbols when
            deciding whether an as-needed shared library is needed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]