Re: 64 bit time_t changes

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

On Fri, Mar 28, 2008 at 08:03:23AM +0000, David Laight wrote:
 > > 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.
 > 
 > Does such a dependency help at all ?
 > If the dependency causes libc.so.12 to be loaded into a program that
 > itself is linked with libc.so.13 all hell will break loose - unless
 > all the function names are versioned as well.

It gives at least some hope of rejecting such programs before they
exhibit undefined behavior. If you *don't* have the dependency, all
hell will still break loose, only you can't tell what's wrong.

To make it work libc.so.13 needs some kind of CONFLICTS entry that
names libc.so.12 as not being allowed to exist at the same time. It
should be possible to do this with a NOTE.

 > The only way is to mark all new binaries as being incompatible with
 > any existing binary so they can't exist in the same program.

Yes, that's the idea.

 > > 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.)
 > 
 > That is likely to be impossible unless the linker reserved space in
 > the elf string table (which it doesn't).

Eh? That depends on where the string table appears in the binary, but
even if it's poorly situated you can always move it somewhere else, or
insert a page-sized amount of space in the file. All you really can't
do is move code and data elements (for which there's longer full
relocation data) relative to page boundaries. It might result in
wasting a page of memory at runtime, but that's a very small price
compared to not working at all.

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