svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib

Konstantin Belousov kostikbel at gmail.com
Wed Apr 2 17:24:51 UTC 2014


On Wed, Apr 02, 2014 at 05:30:51PM +0100, David Chisnall wrote:
> On 2 Apr 2014, at 17:18, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> > This is completely wrong.  You cannot modify FreeBSD 8.x namespace in
> > 11.x HEAD time.
> 
> That was an error, however we are using symbol versioning completely wrongly in FreeBSD anyway (see the last two DevSummit discussions and the wiki page).  New entries should *always* go in the version 0 namespace (so that when they're MFCd the changes Just Work?) and only ever be moved out of there when they are replaced with versions with different semantics.
> 

Regarding the 'version 0', breaking the ABI once more after the years
of efforts by others to keep it usefully stable, best delegated to your
private code.

That said, 'version 0' by default is exactly opposite of what should
be done to fully use the versioning facitily to guarantee the ABI
stability. Instead, each batch of symbol addition must introduce a new
version. This would allow rtld to fix the known defect in the lazy
binding mode, where the application fails eventually instead of startup
failure, on undefined symbol.

> The weird hybrid we have that tries to conflate symbol versions and OS releases manages to get the worst of both worlds.
> 
Yes, there is one guarantee which full use of versioning would provide
but our use does not, but your commit' breakage is unrelated.

> I've now moved it to the FBSD_1.3 namespace, but I would be more in favour of going with the consensus from the last DevSummit and using symbol versioning properly and move them all into the FBSD_1.0 namespace.
> 
Use of 1.3 is equally wrong.  You followup 'fix' does not fix the problem.

> > Also, the ABI of the libc now depends on the compiler which was used to
> > build the library, which is also wrong and ugly.
> 
> No it doesn't.  Read the patch.

It does, I read it.
Now libc depends on the non-standard ABI of non-standard C extension,
implemented by only one compiler.

I strongly suggest you to back this out, to have it widely discussed and
properly reviewed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140402/d5bd1de3/attachment.sig>


More information about the svn-src-head mailing list