https://sourceware.org/bugzilla/show_bug.cgi?id=25120
Nix <nix at esperi dot org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nix at esperi dot org.uk
--- Comment #1 from Nix <nix at esperi dot org.uk> ---
Thanks for the heads-up! I'll get to all of these soon.
1: We can't remove __thread when gold is disabled because libctf is intended to
be usable from outside binutils, and some of those clients might create threads
(and there are existing threaded clients that will switch to libctf once the
shared-lib version is out in 2.34): so this bit has to be threadsafe: there are
still a few parts of libctf that are not threadsafe, but I consider that a bug.
The use of __thread was just a workaround for the lack of a bsearch_r(): it
might be easiest to fix this by just implementing a bsearch_r of my own. Grrrr.
2: Ouch, what an oversight. Fallbacks used to exist but I mistakenly removed
them when integrating everything into binutils. Will definitely fix.
3: I honestly had no idea <byteswap.h> wasn't a purely-glibc thing (I should
have checked, I have uclibc-ng here and everything). Agreed.
4: This is very strange. In 2.33, readelf carefully calls only .o files that do
not cite BFD functions, even indirectly, so ctf-open-bfd.o is never pulled in
and BFD is never needed. (I just checked 2.33, and there are no references to
any ctf-open-bfd.o functions in anything else in libctf, and no references from
readelf either. You can figure out what the dead refs are by #if 0'ing out the
contents of libctf/ctf-open-bfd.c and doing make all-libctf, then rebuilding
readelf and seeing what the reported locus of undefined symbol errors is now.
(objdump will, obviously, fail to build if you do this, because it uses the
functions you just removed, but that's not a problem).
In trunk, we generate two .a / .so's, one containing ctf-open-bfd.o and the
other not, in part to make this separation more explicit, but I really thought
I had it working in 2.33 too.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
