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

[Eric Haszlakiewicz <erh%nimenees.com@localhost>]

On Mon, Jan 05, 2009 at 04:11:02PM -0500, Thor Lancelot Simon wrote:
> 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.

How about:
ln -s libc.so.80 libc.so.90  (or vice versa)
?

Then executable 'foo' will explicitly depend on libc.so.90 and let you
know right away what's wrong when you run it on the 32-bit time_t system.

eric