[PATCH v3 00/33] CTF linking support

[Matthias Klose]

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