Re: HEADS UP: I will be merging christos-time_t by the end of the week

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Mon, Jan 05, 2009 at 03:17:01PM -0500, Thor Lancelot Simon wrote:
> 
> And it *might* be possible to not bump dependent library versions, with
> that set of toolchain modifications (to reject attempts to bring in two
> versions of libc at once).  What do others think?

This does not work, because existing executables will suddenly fail --
the executable itself will have a dependency on libc.so.80, for
example, and libY.so.10.  Now, we replace libY.so.10 with a version
that has a dependency on libc.so.90 -- suddenly the existing
executable fails.

What Christos has done takes care of this case about as elegantly as
possible.  The existing executable will get libc.so.80 (the new version
with the compatibility code) and the _old_ libY.so.10.  This will work.
A new executable will get libc.so.80 (with the compatibility code, which
will be unused in this case) and libY.so.11, which will depend on 
libc.so.80.  This will work.

The problem will arise if you do this:

        * Build executable 'foo' on a new system with libc.so.80 and
          libY.so.11

        * Build libY.so.11 on an old (5.0) system with libc.so.80 (old
          version, no compat code, no 64-bit time_t).

        * Bring executable 'foo' to that system and try to run it.  It
          will have libY.11, but that libY will have 32-bit time_t.

Ow, ow, ow.  But I see no graceful way around this.

Thor