Re: libpthread shared library version number

On Wed, 1 Nov 2006, Alexander Kabaev wrote:

> On Wed, 1 Nov 2006 19:38:41 -0500 (EST)
> Daniel Eischen <deischen_at_freebsd.org> wrote:
>
>> On Wed, 1 Nov 2006, 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.
>>
>> It should be done as part of a larger set of library version bumps.
>> All libraries should be bumped.  I believe kan and kensmith were
>> suppose to be looking at that.  We wanted to enable symble versioning
>> by default, so all libraries would need to be bumped.
>>
>
> I never indicate that I was going to do anything regarding version
> bumps and I still have no plans whatsoever to do so. It probably does
> not make sense to do anything until we have a new GCC in the tree.
> Just a note to someone who is brave enough to volunteer for the task.
>
> Handling of libpthread/libthr is not anyone's idea of fun, as both
> librares are exporting different symbol sets under the same version
> name, stick their dirty hands into rtld internals, etc.

I encountered (and reported) weird problems with threaded apps when symbol 
versioning was enabled. The new csup would fail in areas it shouldn't have 
failed and gdb made it look like some weird stuff was happening 
concurrently. Turning off symbol versioning solved the problem.


-- 
This .signature sanitized for your protection