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_at_ ), but I agree that deciding when to do that when libc.so.7 already broke the ABI in unknown locations is too hard.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:58 UTC