Re: HEADS UP: shared library bump, symbol versioning, libthr change

On 5/11/07, Daniel Eischen <eischen_at_vigrid.com> wrote:
> On Fri, 11 May 2007, Alexander Kabaev wrote:
>
> > On Sun, 6 May 2007 10:07:51 -0400 (EDT)
> > Daniel Eischen <eischen_at_vigrid.com> wrote:
> >
> >> Sometime this coming weekend (May 11-13), I'll be committing the
> >> following patch:
> >>
> >>    http://people.freebsd.org/~deischen/symver/bump_symver.diffs.050207
> >>
> >> What does this do?
> >>
> >>    o All library versions that haven't already been bumped and
> >>      that are not new to 7.0 will be bumped.
> >>
> >
> > Hi,
> >
> > I always had a problem with wholesome bumpings like these.
>
> I also had a problem with doing wholesale bumps, you can probably
> search the archives to find an objectior or two from me.  But
> that is how things have been done in the past, so I was just
> trying to take the path of least resistance.
>
> > What is the
> > justification for such a broad sweep? libc bump CAN NOT be made an
> > excuse for cascaded bumps. FreeBSD does not record LIBC dependency into
> > shared libraries themselves, so as long as libc sybols used by the
> > shared library did not change ABI between libc.so.6 and libc.so.7, old
> > shared libraries will happily work with both.
>
> The only ABI change that I am aware of is get[by]hostname(), but there
> may be others.
>
> > If there are are symbols
> > that are missing or have changed in libc.so.7 that prevent it from
> > being a perfect superset of libc.so.6, can we consider adding them back
> > instead, with FBSD_1.0 version and making changed symbols FBSD_1.1 or
> > some such? Sure, this will break older unversioned -current binaries as
> > they will start resolving to FBSD_1.0 symbols, but your bump will
> > obsolete them too, so -current users will need to recompile either way.
> >
> > I always thought that original LIBC bump was a mistake.
>
> I agree, but the problem is that noone has been keeping track of
> ABI changes and how they affect other shared libraries.  I'm not
> sure what the changes are or what is affected if anything.  I
> think that is the real crux of the matter and why re_at_'s have
> always done wholesale library bumps in the past.
>
> > Please consider this an objection until this matter is discussed in
> > more detail.
>
> At a minimum, all libraries that have been symbol-versioned need
> to be bumped, though.  How about if I commit everything except for
> the bumping of non-symbol-versioned libraries?  After a later
> discussion, re_at_ can decide whether or not to bump the remaining
> libraries.  Is this acceptable?
>

Not really. You've wrote it several times before and I kept forgetting to ask
you why do you think libraries getting versioned symbols need to be
bumped. There might be a valid reason for this, but it somehow escapes me
and I would greatly appreciate you helping me to get this straight. I do not
think breaking binaries linking to symbols to which they had no business to link
in the first place is reason good enough. And testing done by Kris did show
us that the percentage of such binaries extremely small, small enough to be
treated as a noise.

I certainly wouldn't mind you committing everything _but_ version bumping.

Back to libc.so.7 bump mistake. I an this >< close to actually suggest
that we back libc.so.7 bump out  and do things RIGHT for a change.

-- 
Alexander Kabaev