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

[christos%astron.com@localhost (Christos Zoulas)]

In article <20090106203536.GA20900%nimenees.com@localhost>,
Eric Haszlakiewicz  <erh%nimenees.com@localhost> wrote:
>On Tue, Jan 06, 2009 at 01:20:41PM -0500, der Mouse wrote:
>> >> Ow, ow, ow.  But I see no graceful way around this.
>> > How about:
>> > ln -s libc.so.80 libc.so.90  (or vice versa)
>> > ?
>> 
>> Won't that break badly when libc gets "honestly" bumped to .90?
>
>It seems to me like it actually _is_ being bumped to .90 but happens to be
>backwards compatible in a way that allows it to masquerade as a .80 lib.
>If another bump happens, you'd go to .100, and then you'd end up with 
>.80, .90 and .100 all pointing at the same file.  If a bump happens in
>such a way that the compat functions are removed, then those links go away.
>
>btw, does anyone know how the symbol versioning that glibc uses compares
>what we do?

It is better because:
- it does not pollute the headers
- it can differentiate between link time and run time access. I.e. you
  can have a versioned symbol that you can link and run against, or you
  can have a versioned symbol where you cannot link against, but you can
  run an existing binary.

There are probably more things to say here, but these are the first ones
that come to mind.

christos