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

On Sat, 12 May 2007 18:39:23 -0400 (EDT)
Daniel Eischen <deischen_at_freebsd.org> wrote:

> On Fri, 11 May 2007, Daniel Eischen wrote:
> 
> > On Fri, 11 May 2007, Alexander Kabaev wrote:
> >
> >> 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 think it was because I thought libraries and applications that
> > are linked without symbol dependencies would always get the
> > latest version of the symbol, not the earliest version of
> > the symbol.  But if I recall correctly from prior email from
> > you, you should get the earliest version of the symbol in
> > lieu of no recorded symbol dependency?
> 
> libc and the thread libraries need to be bumped for a couple of
> reasons.  I believe the internal jump table (see __thr_jtable
> in src/lib/libc/include/libc_private.h) changed sizes between
> 6.x and 7.x.  The other reason is that libpthread and libthr
> used the namespace LIBPTHREAD_1_0 as their namespace, and this
> needs to be removed and FBSD_1.0 used instead.  libpthread
> currently has to play some ugly games in order to be compatible
> with both namespaces.  libthr currently doesn't have those
> ugly hacks and it would have to add them if its library version
> is not bumped.
> 
> -- 
> DE

Hmm, than does complicate matters a bit and I need to think about this
a little bit more. Could you commit the rest of the patch meanwhile?
It might turn out that another wholesale bump was made unavoidable by
our earlier actions already. I just do not want to rush it :)

-- 
Alexander Kabaev