Subject: Re: Forward-compatibility libpthread for netbsd-4
To: None <tech-userlevel@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-userlevel
Date: 09/28/2007 21:40:35
In article <20070928213405.GA725@britannica.bec.de>,
Joerg Sonnenberger  <joerg@britannica.bec.de> wrote:
>-=-=-=-=-=-
>
>Hi all,
>http://www.netbsd.org/~joerg/libpthread-postsa.tar.gz
>is a somewhat older snapshot of current's libpthread.
>Together with the attached ld.so.conf it would allow netbsd-4 programs
>to run with a current kernel even if they use pthread.
>
>Let me reiterate the problem for a moment. With the merge of the
>newlock2 branch, Scheduler Activation was removed from HEAD.
>libpthread did get a major bump as the old version does not work on
>a post-newlock2 branch. Independent of the question whether SA will be
>merged back into HEAD in the future, this means testing newer kernels
>for fixes etc is not an option. It also makes it harder to use binary
>programs when later migrating to netbsd-5.
>
>The solution with the smallest impact is to provide an override library
>(above is the source) and install it outside the normal search path.
>ld.elf_so gets instructed to use it via ld.so.conf if the kernel doesn't
>support SA. The question is now:
>
>(a) Do we want to have this in the release? If yes, I will update the
>tarball and document how it is generated for possible later updates.
>
>(b) If yes to (a), do we want to install the correct ld.so.conf by
>default?

I think that the answer is yes to both. (Unless we are able to put back
SA in the kernel for 5.0). OTOH the only thing that uses threads in base
is named. Perhaps it is easier to turn threading of in named...

christos