Where is thr_getscheduler

Kostik Belousov kostikbel at gmail.com
Fri Aug 4 14:37:41 UTC 2006


On Fri, Aug 04, 2006 at 08:57:52AM -0400, Daniel Eischen wrote:
> On Thu, 3 Aug 2006, 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?
> 
> We have symbol versioning but it isn't enabled by default
> yet.  We're waiting for the library versions to be bumped
> before enabling it.  We can't support old non-symbol-versioned
> ABIs (e.g. libc.so.6) in a symbol-versioned library so we
> need to bump the library versions before enabling it.
Hmm, yes, libc versioning is disabled. I looked at the libpthread/libthr.
Then, why versioning for threaded libraries is on ?

BTW, as far as I know, there is technical possibility to declare the
"unspecified" version for the symbol (like
	.symver	XXX_old,XXX@
), but I agree that deciding when to do that when libc.so.7 already
broke the ABI in unknown locations is too hard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20060804/9b56d039/attachment.pgp


More information about the freebsd-current mailing list