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