https://sourceware.org/bugzilla/show_bug.cgi?id=26018
Michael Matz <matz at suse dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |matz at suse dot de
--- Comment #8 from Michael Matz <matz at suse dot de> ---
This might have broken usage in the wild. In libqt4 this feature is used as
follows:
g++ ... -shared -Wl,-Bsymbolic-functions -Wl,--dynamic-list,QtCore.dynlist ...
with QtCore.dynlist only containing function names:
-----------------
{
extern "C" {
"qt_startup_hook";
"qt_addObject";
"qt_removeObject";
};
extern "C++" {
"QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)";
};
};
-----------------
The intent is that all functions are bound locally, except for the few ones
explicitely mentioned. That worked fine with binutils 2.32, an excerpt from
the
relocations:
...
00000000004e4bc8 0000047e00000006 R_X86_64_GLOB_DAT 00000000004e5900
_ZN7QString11shared_nullE + 0
...
I've singled out this one because it's important: this shared_null member _must
not_ be bound symbolically, there must be only one in the process image, and
there exist (non-PIE) binaries that contain COPY relocations on it. So
relocations to this symbol need to stay in the shared lib, i.e. it must remain
dynamic.
With binutils 2.35 _ZN7QString11shared_nullE is bound symbolically, there's
no trace of it in the relocation of libQtCore.so.4 anymore, breaking stuff
in interesting ways (e.g. some executables hang at start).
I think what this (old) libqt4 link command is doing is reasonable: it wants
default behaviour for symbol binding, then overrides this for functions (to be
bound symbolically) and then overrides _that_ for some further functions (to
again be bound as per default, i.e. late). I.e. the overall expectation that
data objects remain bound late with that command line seem sensible.
I haven't yet verified if this commit is really at fault, but it looks at least
related and I wanted to leave a trace in case I can't continue with analysis
tomorrow. If it's not this, then it's some other change since 2.32.
--
You are receiving this mail because:
You are on the CC list for the bug.
