Date: Fri, 14 Dec 2007 03:35:07 -0500 From: David Schultz <das@FreeBSD.ORG> To: Daniel Eischen <eischen@vigrid.com> Cc: Yar Tikhiy <yar@FreeBSD.ORG>, Alexander Kabaev <kabaev@gmail.com>, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/msun Symbol.map Message-ID: <20071214083507.GA33635@VARK.MIT.EDU> In-Reply-To: <Pine.GSO.4.64.0712140024230.14620@sea.ntplx.net> References: <200712140308.lBE38Ae7061160@repoman.freebsd.org> <20071213235617.2b554b60@kan.dnsalias.net> <Pine.GSO.4.64.0712140024230.14620@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 14, 2007, Daniel Eischen wrote: > I think we reached some sort of consensus that the namespace would be > bumped for every release...? So unless these get added to 7.0 before > it goes out the door, they should be put in a separate namespace. > > On the other hand, newly added symbols don't break the ABI. I > don't think there is a technical reason why symbols can't be > added to FBSD_1.0 in -current; they can be easily backported > to 7.0. The only reason I can think of---and perhaps this is why Alex was objecting---is that someone could write a library that exports a symbol with the same name but a different purpose. Then a binary that was linked against both that library and libm.so.5 could get different results on later versions of FreeBSD. I think that in general that's a good point for when we add proprietary and non-standard extensions. However, in this particular case, we're talking about a symbol that's reserved for the math library by the C standard. Anyone who exports another symbol with the same name is asking for trouble, and the standard says not to do that. They should have no expectation that such programs will work under any version of FreeBSD. > At a minimum, we need to create one new namespace in each > release branched from -current when there is one or more > ABI changes from the prior release. Perhaps we should just > move to FBSD_1.1 now in 8-current just to make things easier. > When we go to 9-current, we move to FBSD_1.2, etc. If you > need to backport changes back to 7.x, then you also have to > create the matching version in 7.x. The trouble with that is that if I MFC one thing now and another thing between 7.0-RELEASE and 7.1-RELEASE, then people can just as easily complain that I polluted the FBSD_1.1 namespace. The only pedantically correct resolution I can think of is to add a new version for each new symbol that I might possibly ever want to MFC. (Usually I don't plan on MFCing due to limited time, but ports maintainers sometimes ask. This happens less now that we're free from the overly long 4.x release cycle.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071214083507.GA33635>