Re: 64 bit time_t changes

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Mar 22, 2008 at 04:06:10PM -0400, Christos Zoulas wrote:
 > Opinions?

There are two other issues:

First, currently, shared libs aren't linked with -lc when they're
built, so no dependency is recorded; thus one can't readily tell which
library images go with which libc versions. Worse, because of this,
after a libc bump a newly compiled program linked against an old
library and new libc will be silently invalid.

While we definitely need to fix this, and get the fix into 5.0 (and
preferably 4.1) even if no other time_t stuff goes in, we still have
to deal indefinitely with old libs. Regardless of what we do, some
might exist in /usr/local/lib, and users/sysadmins won't necessarily
remember to recompile them even if they *can* recompile them.

Since there might exist libs that legitimately don't record a
dependency on libc, such as maybe app plugins, and new such libs might
be compiled after the version bump, assuming that every libc-less
library image really depends on libc.so.12 isn't safe.

So I think what we need to do is write a tool that inspects old libs
and inserts a libc.so.12 dependency record if the lib uses any libc
symbols. (This is not *completely* foolproof - a library might do
something inane like use only stdio macros - but probably sufficient.)

Probably, we should also add a NOTE reporting that the library has a
correct libc dep (or correctly has no libc dep) and have the dynamic
linker refuse to load libs without such a note. Then the fixup tool
could bless libraries that it's handled and we won't accidentally end
up running anything that won't work.

I think this mechanism is sufficient to be safe, provided other things
come together, and it's not that intrusive (although I'm sure someone
will dislike the idea of rewriting old and maybe irreplaceable shlib
images with additional ELF bits)... but I'm not convinced it's also
necessary, that is, the simplest sufficient solution.


...And second, even bumping libc won't help much with utmp, which is
how we ended up with utmpx in the first place. There's expansion room
in struct utmpx, but not struct lastlogx, so we can either move to
utmpxx or break lastlogx... of these I think breaking lastlogx is
probably better, as utmpxx isn't be very desirable.

The options for the old utmp/wtmp/lastlog files are (1) keep them
around with a 32-bit time field; (2) write a puffs hack to provide
them on the fly based on the utmpx data; or (3) remove them entirely.
I like (2), because it's something we can shunt off to pkgsrc. In any
event I think it's time that code in base stopped reading the old utmp
files. If it hasn't already.

(Another option for everything is to move to utmp.db... since we could
provide both utmp and utmpx as puffs hacks. Although someone would
have to figure out how to handle wtmp in this setup.)

-- 
David A. Holland
dholland%netbsd.org@localhost