Re: libctf linking against different libbfd builds, but using the same soname

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

On 22 Nov 2019, Alan Modra told this:

> On Fri, Nov 22, 2019 at 09:36:14PM +0000, Nick Alcock wrote:
>> On 22 Nov 2019, Alan Modra said:
>> 
>> > On Fri, Nov 22, 2019 at 05:58:00PM +0000, Nick Alcock wrote:
>> >> The only thing we use libbfd for in libctf is to read .ctf sections out
>> >> of BFD-readable objects, and tie them up with likely-relevant string and
>> >> symbol tables in the enclosing object. As long as the native BFD can
>> >> read the relevant objects, nothing bad would happen if you used the
>> >> native one rather than the cross one.
>> >
>> > The thing to keep in mind is that we make no promise to keep the
>> > libbfd ABI stable from one day to the next.  It's also quite easy to
>> > break compatibility between builds using the same source, just by
>> > configuring a little differently, although BFD_INIT_MAGIC helps with
>> > that.
>> 
>> True -- but in that case, the libbfd soname does change (because it
>> changes constantly). Unless someone is quite unlucky and installs libctf
>> and a libbfd from a different, incompatible binutils built on the *same
>> day*... I mean, yes, it's possible, but is it really plausible?
>> 
>> I mean I *could* fix this by linking libctf with libbfd.a:
>
> No, no, there isn't any need for that.  I'm just saying, keep in mind
> that the libbfd ABI can change.  I made my comment in response to you
> saying "nothing bad would happen if you used the native one rather
> than the cross one".  Famous last words.  :)

Hm yeah. It's true that, e.g., if the native one was non-ELF but libctf
was built against an ELF-supporting cross... painful things would happen
(well, probably an unresolved symbol at runtime). I *assume* that the
usual installation of crosses into sysroots would save us there?

I see nothing wrong with decorating sonames to indicate crossness etc,
if that would help. (I just don't want to end up with a
constantly-shifting soname for libctf merely because libbfd has one.)