Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 02 Nov 2006 13:19:37 -0800
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        Ruslan Ermilov <ru@FreeBSD.org>
Cc:        Daniel Eischen <deischen@FreeBSD.org>, current@FreeBSD.org
Subject:   Re: libpthread shared library version number
Message-ID:  <454A60E9.7020303@FreeBSD.org>
In-Reply-To: <20061102182419.GC774@rambler-co.ru>
References:  <454936CA.6060308@FreeBSD.org>	<20061102115058.GB10961@rambler-co.ru>	<Pine.GSO.4.64.0611020824150.12236@sea.ntplx.net>	<20061102140948.GA70915@lor.one-eyed-alien.net> <20061102182419.GC774@rambler-co.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
Ruslan Ermilov wrote:
> On Thu, Nov 02, 2006 at 08:09:48AM -0600, Brooks Davis wrote:
>> On Thu, Nov 02, 2006 at 08:25:37AM -0500, Daniel Eischen wrote:
>>> On Thu, 2 Nov 2006, Ruslan Ermilov wrote:
>>>
>>>> On Wed, Nov 01, 2006 at 04:07:38PM -0800, Maxim Sobolev wrote:
>>>>> Guys,
>>>>>
>>>>> I have noticed that libpthread shared library version number in 6-STABLE
>>>>> and 7-CURRENT is the same (.2), which causes all threaded application
>>>>> compiled for 6-STABLE to segfault when executed on 7-CURRENT system,
>>>>> unless libpthread.so.2 is replaced with with its 6-STABLE version which
>>>>> in turn will create problems with threaded apps compiled for 7-CURRENT.
>>>>> IMHO we should increase version number in 7-CURRENT, so that it is in
>>>>> the line of what we have for other system libraries.
>>>>>
>>>>> Any objections?
>>>>>
>>>> Last time we bumped them was right before 6.0-RELEASE; we did it
>>>> both in HEAD and RELENG_6.  We certainly should be bumping them
>>>> all again closer to a 7.0-RELEASE, when the RELENG_7 is about to
>>>> be created.  If we bump some majors now, and break APIs later but
>>>> still before a release (we are allowed to do it in -CURRENT), we
>>>> would have to bump them again before a release, and because it's
>>> No, in -current we force people to recompile everything.  Plus
>>> we have symbol versioning in the libraries most likely to be
>>> effected.  If we bump, we should enable symbol versioning at
>>> the same time.
>> I agree with the last part, but I think we need to bump sooner rather
>> than later because we need to support binary only applications compiled
>> against 6.x (remember, we're not really supporting anything else so
>> smart vendors are going to build against it).
>>
> Hmm, bumping not versioned libraries *now* and not bumping them
> again at pre-release would work, but doing it without also bumping
> "to be versioned" libraries is IMO pointless.  And if we bump all
> of them now, we'll have to bump some of them again when versioning
> is turned on by default.

No, we will not have to do it. Why would we? It's -CURRENT, so that 
nobody really cares about backward/forward compatibility within that branch.

-Maxim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?454A60E9.7020303>