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

Matthias Klose doko@ubuntu.com
Tue Nov 26 09:00:00 GMT 2019


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.

>>            The packages for Debian/Ubuntu are built with the attached patch,
>> and setting BFD_SOVER_EXT to "-system" for native builds, and to
>> "-$(TARGET_ARCH)" for cross binutils.  Ending up now with conflicting sonames
>> for the native and cross libctf builds. Now I think I should extend the patch
>> below to encode the same information into the libctf soname, so that I am able
>> to distinguish between the native and the various cross builds. Is this correct,
>> or can you discard the cross libctf builds and use the native build instead?
> 
> 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.
> 
> 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.

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

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.

Matthias



More information about the Binutils mailing list