Re: [PATCH v3 00/33] CTF linking support

[Nick Alcock <nick dot alcock at oracle dot com>]

Thanks for the attention! (On a Sunday, no less.)

On 8 Sep 2019, Matthias Klose verbalised:
> On 07.09.19 11:18, Nick Alcock wrote:
>> 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?

The only difference is if the target doesn't support ELF: non-ELF
targets don't have some ELF-specific stuff like ctf_open() of an ELF
object automatically digging out the .ctf section for you. (However, it
*will* include the machinery which shuffles the data object and function
info CTF sections to match the ELF symbol table, because it gets the ELF
symbols via callbacks into the linker that non-ELF targets could
potentially supply. Not that I've written that machinery yet. :) )

(And this difference would apply whether or not the target was native or
cross. libctf does nothing special if host != target or build != host.)

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

I've just dug around and not found a single distro which installs a PIC
libiberty under any name but libiberty_pic.a -- but OK, I'm happy to
shareify libctf.so instead!

My only question is whether the last person to libtoolize a binutils-gdb
subproject knows how it was done: as far as I can tell other parts of
binutils do it using a specific unreleased git commit of libtool, and
hand-hacking of aclocal.m4 etc rather than using libtoolize. And that's
only what I discovered before I gave up trying to libtoolify libctf a
few months ago: is it actually this hard, or am I doing something really
wrong?

-- 
NULL && (void)