Re: Where is thr_getscheduler

On Thu, Aug 03, 2006 at 10:02:43PM -0700, John-Mark Gurney wrote:
> Steve Kargl wrote this message on Wed, Aug 02, 2006 at 10:25 -0700:
> > Almost everything on a FreeBSD system depends on libc.  Bumping
> > its version number without careful coordination of bumping all
> > other version numbers is full of landmines.  Falling back of the
> > retort "this is -current expect problesm" just glosses over what
> > appears to be sloppy planning. 
> 
> Ummm.. don't we have have symbol versioning?  isn't this exactly
> what symbol versioning is for?  I haven't been following this
> particular discussion, but I thought now that we have symbol versioning
> in the tree that we never have to bump the numbers?  or is this failure
> to have a proper document to tell someone what to do when they change
> the API and provide the correct hooks for the new versions?

The situation on the problematic machine is follows:
/lib contains libc.so.7, libc.so.6 and libthr.so.2 (version number
for libthr is not bumped still). libc.so.7 and libpthread.so.2
contain versioned symbols, libc.so.6 is not versioned.

Old build of the application linked against libc.so.6 and libthr.so.2.
References to symbols in libthr.so.2 are satisfied by default
version of the symbols. 

Missing are two things:

1. libpthread/libthr are still not linked against libc (as well as most
shared libraries). Correspondingly, version information for referenced
libc symbols is absent in the shared libraries.

2. check for presence of the required version in the
depended libraries is absent too, IMHO.

Given these two issues are resolved, libthr.so.2 (and libpthread.so.2)
references to libc would be unsatisfied with different diagnostic.

I added kan_at_ to the mail loop, but he seems to be unreacheable for some time
now.