Re: CVS commit: src/lib

[Sverre Froyen <sverre%viewmark.com@localhost>]

On 2013-03-25, at 20:14, Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:

> It would fix one instance of the problem, but it will appear again
> somewhere else later. We cannot expect third party program to always do
> The Right Thing, especially when it is outside of any specification: no
> standard has a word on it, and to make things worse, Linux lets you
> dlopen a DSO with -lpthread

Having followed this debate somewhat cursory, I may way off base. I cannot help 
wonder, however, if we should look at this issue from the opposite direction. 
What if we turn on the "machinery" needed in order to support pthread by 
default? I believe this amounted to some extra locking code. This would add 
unnecessary overhead to non-threaded programs, but I'm guessing that for most 
programs this overhead would not be noticeable. Then, to accommodate programs 
where this overhead is unacceptable, add a "no-pthread" option that restores 
the current behavior. Seems to me this kind of change is not unprecedented and 
rather similar to the case, years ago, when we switched from static to dynamic 
linking.

Finally, I have a question about the degree of the "regression". Typically, 
NetBSD has provided a high degree of binary compatibility. In the past, when I 
have upgraded the system code, most (all?) packages continue to function 
without having to be recompiled. In this case, that appears not to be the case. 
Do the latest changes restore binary compatibility?

Regards,
Sverre