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

[Nick Alcock]

This is slowly starting to come clear to me. At last :)

On 26 Nov 2019, Matthias Klose uttered the following:
> On 22.11.19 18:58, Nick Alcock wrote:
>> On 22 Nov 2019, Matthias Klose verbalised:
>> 
>>> I made a first attempt at packaging binutils trunk and libctf.  Two new shared
>>> libraries are installed, libctf and libctf-nobfd.  libctf-nobfd is the same
>>> library for native builds, and for builds targeting other architectures, however
>>> the libctf builds are differing, because they link to different libbfd
>>> libraries.
>> 
>> ... I suppose so. Does this matter?
>> 
>> For a cross build, I'd expect libctf.so.* and libctf-nonbfd.so.* to go
>> into an arch-triplet-named sysrooted libdir anyway
>> (/usr/aarch64-unknonwn-linux-gnu/lib etc): the libdir copy is usually
>> reserved for native builds. I guess Debian multiarch makes this a bit
>> different, but the general rule of not stuffing cross shared libraries
>> in the same libdir as non-cross shared libraries surely remains. (If I
>> have to do something special to make that happen, and I've not noticed,
>> I'd be happy to do it. Multiarch is a wonderful thing and should be
>> encouraged.)
>
> When packaging the cross toolchain, I was moving everything into the system
> libdirs.  The libctf.so.* and libctf-nonbfd.so.* libraries are host libraries,
> not target libraries, and installing those together with the native binutils
> build, you'll see the file conflicts.
>
> /usr/<target-triplet> is only used for the target libraries, not for any tool
> specific host libraries.

Oh. So there's nowhere to put host libraries whose contents vary
depending on the target? That's something upstream got right, I think...
and obviously I don't want something *in* upstream to diverge from
de-facto upstream standards here. (If Alan would rather I name cross
libctf.so's differently too, I'm happy with that: but cross libbfds
aren't named differently from non-cross libbfds, so this feels like it
would be inconsistent.)

>> However... if you build with --enable-shared, ld ends up linking against
>> libctf as well (obviously) as bfd. I'm fairly sure bad things would
>> happen if libctf was linking against a *different* bfd than the ld that
>> used it, at least unless we tried to hide the symbols used internally to
>> libctf (using DT_GROUP or -Bsymbolic or something: that's nonportable,
>> of course, which might cause trouble if you built an ELF cross on a
>> non-ELF platform... and it feels like papering over the problem.)
>
> yes, built with --enable-shared. I suppose I could build the cross binutils with
> --disable-shared as well, package sizes would increase.

Yeah, that's not as nice but it's a common ugly workaround. I'd agree we
should avoid ugly workarounds if possible.

>> Basically, BFD usage is a small part of libctf, and I was really hoping
>> that I wouldn't have to perturb the entire soname or do something else
>> massively disruptive just because of the library we're using to pull
>> sections out of executables. But really as long as users can just say
>> -lctf to link with it I guess it's not too problematical if the SONAME
>> they end up linking with is cross-specific. (It shouldn't be a
>> constantly-changing soname, though. Unlike libbfd, we have a stable
>> API/ABI in libctf, at least mostly, and I'd like to stick with that if
>> possible, with exceptions for newly-added and still evolving bits like
>> ctf_link_*().)
>
> Assume you had a configure option --with-system-libctf, linking the cross
> binutils against the libctf from the native binutils build ... would that work,
> or not, for any combination of the native and the cross architecture?
> Same question for --with-system-libctf-nobfd.

Well, the question really is if libbfd's API or ABI or macro contents
etc changes if you change the target, and I fear it probably does. This
probably torpedoes your cross ld as well unless you change the soname
for libbfd as well.

> If that does work, then a set of configure options would be nice.
> If it's not supposed to work, then I think I have to change the soname.

If you're changing the soname for cross libbfd, I suspect you'd need to
change the soname for all shared-library users of that cross libbfd,
including libctf.

-- 
NULL && (void)