On Fri, May 16, 2025 at 10:11:12AM -0400, Mark Johnston wrote:
> On Fri, May 16, 2025 at 03:22:52PM +0300, Andriy Gapon wrote:
> > On 27/04/2025 17:26, Mark Johnston wrote:
> > > On Thu, Apr 24, 2025 at 08:56:44AM +0300, Andriy Gapon wrote:
> > > > On 23/04/2025 21:56, Andriy Gapon wrote:
> > > > > BTW, I've been wondering how illumos avoids the problem even though
> > > > > they
> > > > > do not use any special dlopen flags.
> > > > > It turns out that they link almost all system shared libraries with
> > > > > -Bdirect option (which is Solaris/illumos specific).
> > > > > It's somewhat similar to, but different from, -Bsymbolic.
> > > > > https://docs.oracle.com/cd/E23824_01/html/819-0690/aehzq.html#scrolltoc
> > > > > https://docs.oracle.com/cd/E36784_01/html/E36857/gejfe.html
> > > >
> > > > Oh, and it looks like there is an even better explanation for illumos.
> > > > There is a version map file for libdtrace which explicitly lists API
> > > > functions and makes everything else local.
> > > > https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libdtrace/common/mapfile-vers
> > > >
> > > > I wonder why we didn't do the same when porting.
> > > > Maybe we should do that now?
> > >
> > > I don't have any objection, but I believe adding a version map after the
> > > fact doesn't accomplish much, assuming that we care deeply about ABI
> > > stability in libdtrace.so (I'm not sure we do though).
> >
> > My primary goal here is not ABI stability, but hiding symbols that really
> > should not be exported. See more at the end.
> >
> > At the same time I am not sure why it could be too late to start caring
> > about ABI stability now. Assuming we actually would want to do that.
>
> I just mean that the version map helps only helps provide stability for
> binaries linked to libdtrace.so after the version map is introduced.
This is one of the reason why versioning the library requires bumping
the .so file version.
