This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH v3 00/33] CTF linking support
On 07.09.19 11:18, Nick Alcock wrote:
On 7 Sep 2019, Matthias Klose uttered the following:
On 07.09.19 00:54, Nick Alcock wrote:
As another change in this series, we make libctf into an installable
(.a) library, so that external programs can benefit from the new libctf
linking API, to link CTF like ld does. Since libctf uses libiberty, and
many plausible uses link libctf.a into a shared library, this also
requires us to install the PIC version of libiberty: most distros are
doing this already, so this is probably worth doing regardless.
Speaking for the Debian/Ubuntu builds, I'm not that keen to have to
ship a shared libiberty library ...
Well, it's not shared -- it's a static PIC library suitable for
inclusion *into* shared libraries. But I know what you mean. :)
Why can't that be done like for
libbfd and libopcodes, to include the convenience libiberty into the
shared libaries?
That's what I'm doing -- but the consumer of libctf is not necessarily
part of binutils, and since libctf is not shared yet, a libctf user in
a shared library has to have access to PIC versions of every library
which libctf itself uses.
ok, misunderstood that.
The libbfd build has a nice feature to include an extra name into the library name, e.g. libbfd-2.32.51-system.20190821.so, or for
cross builds libbfd-2.32.51-ppc64el.20190821.so. It would be nice if libctf could provide a similar schema, assuming that libctf
doesn't have a stable ABI like libbfd.
It does have a stable API/ABI. Once it goes shared, I was planning to
link libiberty_pic.a into it and hide its symbols from the outside
world, but I wasn't sure people would be happy shipping a new shared
library nor that this was all *quite* stable enough yet (in particular,
the newest bits like the the ctf_link API are almost certain to change
as the deduplicator lands, though the rest is long-term stable: but that
bit is so new that this is not going to affect anyone, since there are
no other public users yet and obviously the binutils user in ld will be
changed in the same commit).
And libctf is the same for native builds, and builds targeting cross toolchains?
If people are happier making a shared-and-installed libctf.so than they
are installing the libiberty_pic.a which binutils already builds, I can
do that, but frankly I thought it would be much *more* controversial,
multiple distros already installing libiberty_pic under that name. I
suspected the non-installation of libiberty_pic in binutils upstream was
an oversight.
I think installation and even naming of any _pic.a library is distro specific.
Matthias