Date: Sun, 16 Dec 2007 17:03:45 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Daniel Eischen <deischen@freebsd.org> Cc: Kabaev <kabaev@gmail.com>, David Schultz <das@freebsd.org>, Yar Tikhiy <yar@freebsd.org>, cvs-all@freebsd.org, Alexander Subject: Re: cvs commit: src/lib/msun Symbol.map Message-ID: <20071216170345.384e6e06@deskjail> In-Reply-To: <Pine.GSO.4.64.0712141118200.16719@sea.ntplx.net> References: <200712140308.lBE38Ae7061160@repoman.freebsd.org> <20071213235617.2b554b60@kan.dnsalias.net> <Pine.GSO.4.64.0712140024230.14620@sea.ntplx.net> <20071214083507.GA33635@VARK.MIT.EDU> <Pine.GSO.4.64.0712141118200.16719@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Daniel Eischen <deischen@freebsd.org> (Fri, 14 Dec 2007 11:31:46 -0500 (EST)): > On Fri, 14 Dec 2007, David Schultz wrote: > > > 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. > > No, that's not the reason - see Alex' other email. > > >> 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.) > > No, everytime we branch a release from -current (e.g, at 8.0, > 9.0, etc), we should increment the namespace. -current typically > stays at the same number for quite a while (1-3 years?). We > go to FBSD_1.1 now in 8-current. Check with re@ and see if I don't know much about the policy for symbol versioning, but from reading some mails here I'm a little bit puzzled. Wouldn't it make more sense to go to FBSD_2.0 in -current, so that we can go to FBSD_1.1 for 7.1 if needed? This way we can add new symbols for 7.1 in the FBSD_1.1 namespace. If we do it like this (I don't know if this is possible, or if an increase of the major number has a different meaning in the current policy), applications compiled for 7.1 which use the new symbols, give a better understandable error message to the user (when he looks up FBSD_1.1 he sees it is the namespace for a change in 7.1). > you can MFC your symbols before 7.0. If not, then move them > to FBSD_1.1 in -current. If you have to MFC symbols from > FBSD_1.1 in -current, then just add those symbols to FBSD_1.1 > in 7.x. And here a big part of lack of understanding for this shows up on my side. If I have a library with symbols from the FBSD_1.1 namespace, I can not expect that it has all the symbols from the FBSD_1.1 namespace. The problem on my side is, that I would expect that it contains all the symbols from the FBSD_1.1 namespace of this library. With our old scheme (library versioning without symbol versioning), this was the case. I don't know what the best solution would be, as I'm not that deep in toolchain issues, but whatever the way is we go, we should document changes like this (maybe it's even POLA..., at least I think it is a very big change) promintently. > Whatever happens, the symbols in release N.x must be present in > the same namespaces as release N.x+y through -current to > maintain backward compatibility. The opposite is not true, > as release N.x+y can contain a superset of symbols from > release N.x. Bye, Alexander. -- I'm DESPONDENT ... I hope there's something DEEP-FRIED under this miniature DOMED STADIUM ... http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071216170345.384e6e06>