On Wed, 30 Aug 2000, Andy Dougherty wrote:
> On Tue, 29 Aug 2000, Russ Allbery wrote:
>
> > Not a big deal, and that's certainly doable. But it's possible to do more
> > than that if you really want to. The glibc folks have decided to comment
> > to nearly full binary compatibility for essentially forever; the theory is
> > that upgrading libc should never break a working application even if the
> > ABI changes. I'm not familiar with the exact details of how symbol
> > versioning works, but as I understand it, this is what it lets you do.
>
> I'm sure the glibc folks indeed work very hard at this and are largely
> successful. I also know, however, that over the past couple of years or
> so, I've had to recompile nearly all of my applications on several
> occasions when I've upgraded glibc. Other times, glibc upgrades have gone
> without a hitch. It's probably my fault and probably somewhere deep in my
> personal library I'm incorrectly fiddling with stdio internals or
> something, but I just wanted to offer a counter data point that doing
> this sort of this robustly is, indeed, very hard.
I think we can pull this off if we're careful and draw really strict lines
about what is and isn't public stuff. It's not easy, and it will mean
we'll have to have some reference executables in a test suite for
verification, but I think we can manage that.
I do want to have a set of C/XS/whatever sources as part of the test suite
as well--right now perl's test suite only tests the language, and I think
we should also test the HLL interface we present, as it's just as
important in some ways.
dan
