bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/28879] New: [2.38 Regression] ld.bfd: possibly incorrect "undefi


From: evangelos at foutrelis dot com
Subject: [Bug ld/28879] New: [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
Date: Thu, 10 Feb 2022 16:27:44 +0000

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

            Bug ID: 28879
           Summary: [2.38 Regression] ld.bfd: possibly incorrect
                    "undefined reference" errors
           Product: binutils
           Version: 2.39 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: evangelos at foutrelis dot com
  Target Milestone: ---

Created attachment 13969
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13969&action=edit
Small example with pre-built objects

The attached tarball contains a small example of an issue I'm seeing on Arch
Linux after upgrading to binutils 2.38. It's a trimmed down version of the
linking errors I get when trying to build libheif [1] with CXXFLAGS="-flto
-Wp,-D_GLIBCXX_ASSERTIONS" LDFLAGS="-Wl,--as-needed". I was unable to repro
with a few minimal examples I tried, so please excuse the binary test case.

Bisect pointed to commit 7de7786bb7db [2] as the first revision that exhibits
linking failures when building libheif with LTO. Adding "libx265.so.199" to end
of the g++ line in repro.sh allows it to link, so there appears to be some
issue with looking up some libstdc++ symbols used by libx265 when it's linked
indirectly through libheif.so.

(Please note that libheif and libx265 are used as an example here; they were
just the first packages that showed this issue after upgrading the toolchain to
gcc 11.2, glibc 2.35 and binutils 2.38.)

FWIW, searching for the first symbol in the attached object files I see:

-----------------------------------
heif_info-heif_info.o (readelf --lto-syms):

  _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm   
WEAKDEF     DEFAULT

libheif.so (readelf -Ws):

  FUNC    LOCAL  DEFAULT   13
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm

libx265.so.199 (readelf -Ws):

  GLOBAL DEFAULT  UND
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm@GLIBCXX_3.4.21
-----------------------------------

My linker knowledge is limited, but perhaps you might be able to make sense of
all this. :)

[1] https://github.com/strukturag/libheif
[2] https://github.com/bminor/binutils-gdb/commit/7de7786bb7db

==================================
$ cat repro.sh
#!/bin/bash
# objects below built w/ CXXFLAGS="-flto -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-Wl,--as-needed"
LD_LIBRARY_PATH=$PWD g++ heif_info-heif_info.o libheif.so

$ ./repro.sh
/usr/bin/ld: /../heif-link-failure/libx265.so.199: undefined reference to
`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21'
/usr/bin/ld: /../heif-link-failure/libx265.so.199: undefined reference to
`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>::_M_mutate(unsigned long, unsigned long, char const*, unsigned
long)@GLIBCXX_3.4.21'
/usr/bin/ld: /../heif-link-failure/libx265.so.199: undefined reference to
`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>::~basic_string()@GLIBCXX_3.4.21'
/usr/bin/ld: /../heif-link-failure/libx265.so.199: undefined reference to
`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>::_M_replace(unsigned long, unsigned long, char const*, unsigned
long)@GLIBCXX_3.4.21'
==================================

-- 
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]