tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: 64 bit time_t changes




On Mar 22, 2008, at 3:22 PM, Steven M. Bellovin wrote:

On Sat, 22 Mar 2008 16:06:10 -0400 (EDT)
christos%zoulas.com@localhost (Christos Zoulas) wrote:

I can do the work, but I am beginning to wonder if this is the time to
bump libc, and get rid a lot of the compat code that we've collected
through the years? We can use this to sanitize size_t across all the
platforms and do the rest of the cleanup that is mentioned in
shlib_version.

What I am afraid is going to happen if we provide all this
compatibility stuff, is that:
        1. libc will bloat a lot more.
        2. since time_t is such a big abi change
           [timeval, timespec, itimer stuff, rusage, ktrace, just to
mention a few change], if we don't bump libc, we are going to cause
            confusion with mixing 3rd party libraries that are
compiled before and after the time_t change.

Opinions?

Interesting question.  Let me me ask a couple of questions.

First -- will 5.0 ship with the old libc?  If not, I assume that all
binaries, both pkgsrc and user-written, will have to be recompiled.

Second -- when did we last bump libc?

Third -- if we're going to do it, what other changes should we make at
the same time?

One way to help with a new major, is to make libc.12 which just has wrappers
for calls into libc.13.  The hard part is things like _res.


Home | Main Index | Thread Index | Old Index