cvs commit: src/lib/msun Symbol.map
das at FreeBSD.ORG
Fri Dec 14 00:35:17 PST 2007
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.)
More information about the cvs-all