[PATCH v3 00/33] CTF linking support

[Nick Alcock]

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.

> 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).

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.

>> But despite the caveats in that patch, in conjunction with a CTF-capable
>> GCC,
>
> I assume this is for GCC trunk, or are you planning to maintain a CTF branch for GCC 9?

GCC trunk -- AIUI a backport to GCC 9 has been done and works, but
getting the CTF-capable GCC patches accepted into trunk is obviously the
first thing to think about before backports!

-- 
NULL && (void)