On Wed, 28 May 2008, Alexander Kabaev wrote:
On Tue, 27 May 2008 20:04:28 +0000 (UTC) Xin LI <[EMAIL PROTECTED]> wrote:delphij 2008-05-27 20:04:27 UTC FreeBSD src repository Modified files: (Branch: RELENG_6) include string.h lib/libc/string Makefile.inc memchr.3 sys/sys param.h Added files: (Branch: RELENG_6) lib/libc/string memrchr.c Log: MFC: Add memrchr(3). Obtained from: OpenBSD Revision Changes Path 1.21.2.2 +1 -0 src/include/string.h 1.34.8.2 +2 -1 src/lib/libc/string/Makefile.inc 1.7.14.3 +28 -3 src/lib/libc/string/memchr.3 1.1.4.1 +40 -0 src/lib/libc/string/memrchr.c (new) http://cvsweb.FreeBSD.org/src/lib/libc/string/memrchr.c?rev=1.1.4.1&content-type=text/plain 1.244.2.37 +1 -1 src/sys/sys/param.h http://cvsweb.FreeBSD.org/src/include/string.h.diff?r1=1.21.2.1&r2=1.21.2.2 http://cvsweb.FreeBSD.org/src/lib/libc/string/Makefile.inc.diff?r1=1.34.8.1&r2=1.34.8.2 http://cvsweb.FreeBSD.org/src/lib/libc/string/memchr.3.diff?r1=1.7.14.2&r2=1.7.14.3 http://cvsweb.FreeBSD.org/src/sys/sys/param.h.diff?r1=1.244.2.36&r2=1.244.2.37There are two levels of symbol versions checking: 1. Up-front checking of version name. When binary starts, rtld checks that all versions it was compiled against are provided by the dynamically loaded libraries. I.e. if libc.so.7:FBSD_1.1 is recorded as a requirement in binary and given libc.so.7 does not have that version, the binary execution is terminated right on the spot. The assumption here is that if version FOO is claimed to be provided by the library then _all_ [EMAIL PROTECTED] binary might need are present. This is the level of symbol versions checking Solaris provides. Linux goes a bit further: 2. Per-symbol versions. In addition to the above, ld encodes required version of each undefined symbol in a binary and uses (name, version) pair to resolve undefined references as opposed to using only the symbol name. This allows for several versions of the same symbol to exist within the binary, i.e. something like [EMAIL PROTECTED] and [EMAIL PROTECTED] are now possible. Your changes broke assumption in 1. To do it 100% correctly, we probably need to introduce a side version for memchr, something like memrchr@@FBSD_1.0a in stable branch and provide a compatibility alias [EMAIL PROTECTED] for it in -current at the same time. libc.so.7 from RELENG_7 will have: memrchr@@FBSD_1.0a libc.so.7 from -current then will have: memrchr@@FBSD_1.1 [EMAIL PROTECTED] -> memrchr@@FBSD_1.1
Interesting, as long as "a" = ".1", so that you have FBSD_1.0.1 as the side version. See my prior email - I thought we agreed that we just MFC the version (in this case, FBSD_1.1) from -current. If you introduce a new version, a binary built on 7.x may not run on -current from before the side version was added. For instance, if we were to add memfoo() in -current now, then we release 8.0 with memfoo@@FBSD_1.1, then after the release we MFC memfoo() to RELENG_7 in the way you describe, then anything built in RELENG_7 using memfoo() will not work in 8.0 release (because 8.0 didn't have the side version memfoo@@FBSD_1.0a/1.0.1). Typically before a release there are a flurry of MFCs, so you can have a few months or more elapse before the addition of new or ABI-changed symbols. If we just use the same version as -current, then things will just work, at least from when the symbol was changed/added in -current. But regardless, I think this means that once we release 8.0, we cannot MFC any new or changed symbols (from 8.0+) back to 7.x. If someone upgrades from 7.x to 8.0, then 8.0 has to have all the symbols that 7.x will have or else binary compatibility will be broken. -- DE _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
