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

Message ID 476c20f0-89fb-169a-0a87-e9361390df20@ubuntu.com
State New
Headers show
Series
  • libctf linking against different libbfd builds, but using the same soname
Related show

Commit Message

Matthias Klose Nov. 22, 2019, 5 a.m.
Nick,

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.  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 other question I didn't look into detail yet: Does the linking of libctf
against libbfd change any of the libctf ABI?

Matthias

Comments

Nick Alcock Nov. 22, 2019, 5:58 p.m. | #1
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.)

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

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_*().)

> The other question I didn't look into detail yet: Does the linking of libctf

> against libbfd change any of the libctf ABI?


Some symbols (e.g. ctf_open(), ctf_fdopen()) will not be available at
all in the absence of BFD, but those symbols are always the same if
present, and act the same: the crossness of the BFD doesn't affect that.

The most that does happen is that a non-ELF libctf isn't going to dig
out associated string and symbol tables, but then since non-ELF objects
don't try to share their CTF string tables with the enclosing (non-ELF)
object file, nor have mappings from symtab entries to CTF type IDs, this
should have no discernible consequences. (And if we did gain non-ELF
support for some of those, ctf_open etc would start working for them as
well.)

(All BFD usage in libctf is localized inside libctf/ctf-open-bfd.c. Its
use is not very complicated: the most we are doing is finding CTF
sections and figuring out any associated strtab and symtab. :) )
Alan Modra Nov. 22, 2019, 9:33 p.m. | #2
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.

-- 
Alan Modra
Australia Development Lab, IBM
Nick Alcock Nov. 22, 2019, 9:36 p.m. | #3
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: since we
don't export any of its symbols this would work fine, but it would be a
bit bloated. (OK, probably very bloated). Doing that feels... wrong. But
maybe it's better than the alternative?

-- 
NULL && (void)
Alan Modra Nov. 22, 2019, 11:37 p.m. | #4
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.  :)

> since we

> don't export any of its symbols this would work fine, but it would be a

> bit bloated. (OK, probably very bloated). Doing that feels... wrong. But

> maybe it's better than the alternative?


-- 
Alan Modra
Australia Development Lab, IBM
Nick Alcock Nov. 22, 2019, 11:43 p.m. | #5
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.)
Matthias Klose Nov. 26, 2019, 9 a.m. | #6
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
Nick Alcock Nov. 26, 2019, 2:56 p.m. | #7
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)
Andreas Schwab Nov. 26, 2019, 3:38 p.m. | #8
On Nov 26 2019, Matthias Klose wrote:

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


Target-specfic host libraries should be installed in
$(exec_prefix)/$(host_noncanonical)/$(target_noncanonical)/lib, see
AM_INSTALL_LIBBFD in bfd/acinclude.m4.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Matthias Klose Nov. 26, 2019, 3:46 p.m. | #9
On 26.11.19 16:38, Andreas Schwab wrote:
> On Nov 26 2019, Matthias Klose wrote:

> 

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

> 

> Target-specfic host libraries should be installed in

> $(exec_prefix)/$(host_noncanonical)/$(target_noncanonical)/lib, see

> AM_INSTALL_LIBBFD in bfd/acinclude.m4.


yes, I know, however that needs RPATH settings, and doesn't conform to Debian
policy. It's perfectly fine to do that upstream.

Matthias
Matthias Klose Nov. 26, 2019, 3:51 p.m. | #10
On 26.11.19 15:56, Nick Alcock wrote:
> 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.)


Well, Alan was the one to ask that that the system provided libbfd and
libopcodes should have a different soname as well ;).  I'm ok to have local
patches applied, but want to understand the issue to package things correctly.

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


Yes, I'm using different sonames for the cross libbfd as well. Ok, in this case,
I'll just use the same approach for both libctf libraries.

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


Ok, I'll do that.  Thanks for discussing that.

Matthias
Nick Alcock Nov. 26, 2019, 10:10 p.m. | #11
On 26 Nov 2019, Matthias Klose verbalised:
> On 26.11.19 15:56, Nick Alcock wrote:

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

>

> Yes, I'm using different sonames for the cross libbfd as well. Ok, in this case,

> I'll just use the same approach for both libctf libraries.


OK. I'd say it's the native library that shouldn't change: people doing
cross builds are already, alas, too used to doing local hacks.

(But in the longer term it would be nice if Debian had a more systematic
way to do this, i.e. some way to specify "native but targetting cross"
using multiarch: /usr/lib/$native/$cross perhaps:
/usr/lib/x86_64-pc-linux-gnu/aarch64-pc-linux-gnu/ or something.)

Patch

--- a/bfd/Makefile.am
+++ b/bfd/Makefile.am
@@ -958,14 +958,14 @@  bfdver.h: $(srcdir)/version.h $(srcdir)/
 	@echo "creating $@"
 	@bfd_version=`echo "$(VERSION)" | $(SED) -e 's/\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\).*/\1.00\2.00\3.00\4.00\5/' -e 's/\([^\.]*\)\..*\(..\)\..*\(..\)\..*\(..\)\..*\(..\)$$/\1\2\3\4\5/'` ;\
 	bfd_version_string="\"$(VERSION)\"" ;\
-	bfd_soversion="$(VERSION)" ;\
+	bfd_soversion="$(VERSION)$(BFD_SOVER_EXT)" ;\
 	bfd_version_package="\"$(PKGVERSION)\"" ;\
 	report_bugs_to="\"$(REPORT_BUGS_TO)\"" ;\
 	. $(srcdir)/development.sh ;\
 	if test "$$development" = true ; then \
 	  bfd_version_date=`$(SED) -n -e 's/.*DATE //p' < $(srcdir)/version.h` ;\
 	  bfd_version_string="\"$(VERSION).$${bfd_version_date}\"" ;\
-	  bfd_soversion="$(VERSION).$${bfd_version_date}" ;\
+	  bfd_soversion="$(VERSION)$(BFD_SOVER_EXT).$${bfd_version_date}" ;\
 	fi ;\
 	$(SED) -e "s,@bfd_version@,$$bfd_version," \
 	    -e "s,@bfd_version_string@,$$bfd_version_string," \
--- a/bfd/Makefile.in
+++ b/bfd/Makefile.in
@@ -2076,14 +2076,14 @@  bfdver.h: $(srcdir)/version.h $(srcdir)/
 	@echo "creating $@"
 	@bfd_version=`echo "$(VERSION)" | $(SED) -e 's/\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\).*/\1.00\2.00\3.00\4.00\5/' -e 's/\([^\.]*\)\..*\(..\)\..*\(..\)\..*\(..\)\..*\(..\)$$/\1\2\3\4\5/'` ;\
 	bfd_version_string="\"$(VERSION)\"" ;\
-	bfd_soversion="$(VERSION)" ;\
+	bfd_soversion="$(VERSION)$(BFD_SOVER_EXT)" ;\
 	bfd_version_package="\"$(PKGVERSION)\"" ;\
 	report_bugs_to="\"$(REPORT_BUGS_TO)\"" ;\
 	. $(srcdir)/development.sh ;\
 	if test "$$development" = true ; then \
 	  bfd_version_date=`$(SED) -n -e 's/.*DATE //p' < $(srcdir)/version.h` ;\
 	  bfd_version_string="\"$(VERSION).$${bfd_version_date}\"" ;\
-	  bfd_soversion="$(VERSION).$${bfd_version_date}" ;\
+	  bfd_soversion="$(VERSION)$(BFD_SOVER_EXT).$${bfd_version_date}" ;\
 	fi ;\
 	$(SED) -e "s,@bfd_version@,$$bfd_version," \
 	    -e "s,@bfd_version_string@,$$bfd_version_string," \