[PATCH] bfd: include: sframe: fix PR ld/32789

[Michael Matz]

Hello,

On Thu, 18 Dec 2025, Indu Bhagat via Binutils wrote:

> >> This is achieved by adding an explicit argument (bool sort_fde_p) to the
> >> sframe_encoder_write API.  Move the API from 2.0 to the 2.1 node as this
> >> is an ABI-incompatible change.  Skip bumping the "current" in
> >> libsframe/libtool-version ATM, we will do so closer to release.
> > I keep being concerned of such movements, but it also remains unclear to
> > me whether the library is actually intended for any out-of-tree
> > consumption. If it is, shouldn't the existing API stay in 2.0, with its
> > implementation simply being a thin wrapper around the new (2.1) API?
> > 
> 
> The library is not meant for out-of-tree consumption. But it is an installed
> .so, so I followed the general recommendation.
> 
> Is there is a way to convey that this is not meant for out-of-tree consumption
> ?

Don't install the .so symlink, only the .so.X and .so.X.Y.Z ones.  Then 
noone can link-edit against it by a mere -lsframe.  That's what we're 
doing with the binutils package for libbfd and libopcodes; people can 
still link-edit against them, but only if they are willing to jump 
through hoops, which seems to effectively convey "don't do that".


Ciao,
Michael.