Subject: Re: threads support (scheduler activation) and libraries
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 06/25/2002 12:27:50
[ On , June 25, 2002 at 11:41:37 (-0400), Perry E. Metzger wrote: ]
> Subject: Re: threads support (scheduler activation) and libraries
> Doing a major version bump of libc is actually quite easy. We simply
> have to bump the major version number of practically everything.
> More seriously, we ultimately need to figure out how to deal with this
> problem. We can't be paralyzed by it forever.
Yes. Thank you!
I have one suggestion that's not pretty, and perhaps not complete as I'm
not an expert on all these versioning tricks (I'd rather avoid them),
but.... How about just duplicating the lib source tree for every major
level bump, and by default rebuild and install the old libraries too.
Perhaps this'll require keeping the old libraries up-to-date with some
of the system call changes and such, and of course it'll still require
keeping compatability interfaces in the kernel as is done now too for
static binaries. However it'll still allow for bug fixes in the old
libraries, and after all isn't this the one real guaranteed benefit of
Those of us who only build by source can turn this extra build off and
erase our old libraries (just as we now turn off kernel compatability
for static binaries), and everyone else can have fresh-built bug-fixed
binary libc.so's that are compatible with both their new kernels and
their old applications.
It is a very measurable cost -- though unfortunately unlike rebuilding
the world from source on every upgrade it's a more cumulative and ever
increasing cost (though perhaps it's offset by being centrally shared).
It might sound like a maintenance nightmare, but that's what some folks
say about rebuilding everything from source all the time and yet many of
us do the latter. Personally I think this versioning stuff is more of a
maintenance nightmare! :-)
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>