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

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

On Tue, Jan 06, 2009 at 09:52:06AM +1100, matthew green wrote:
 >    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.
 > 
 > 
 > 
 > this isn't supported anyway.  you're basically trying to
 > run a new app on an old OS, because the app was built with
 > the new libc.  i don't see how this is a problem we don't
 > already have and ignore.

The problem also occurs the other way around:

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

  * Build the new libc.so.80 and libY.so.11.

  * Run the executable 'foo'. It will get old timevals from libc and
    new timevals from libY, and demons will fly out of its nose.

This is caused when libY re-exports part of libc's ABI in its own ABI.
Then, recompiling libY with the new libc produces a new incompatible
libY with a different ABI, which won't work with old binaries. In
order to avoid breaking compat, you need to keep the old libY around
and use it independently, and that means a major version bump.

(Alternatively you can version the necessary parts of libY's ABI, so
libY also provides two binary interfaces, each connected to libc in
the correct fashion. However, this isn't trivial, doesn't scale to
things like the X libraries, and I don't think we currenly have the
facilities to support it anyway.)

If libY does not re-export any (changed) part of libc's ABI at all,
then it doesn't need to be bumped, or even necessarily recompiled.

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