Re: Better soname linking

[Jan Engelhardt]

On Wednesday 2009-11-04 21:05, Kurt Roeckx wrote:
>
>> What if a symbol has kept its name, yet changed in semantics?
>
>Then you either shouln't say the API is compatible (and change
>soname), or provide 2 versions of that symbol, like for instance
>libc6 does.

Well let's exclude glibc right from the start from this discussion,
because it _does_ muck with symbol tables, linker scripts and all the
scary stuff to ensure its ABI compatibility. Almost like the Linux
kernel. -- And libtool, just touching the comparison here, does none
of that, of course because the portability of adding extra symbol
info to object files is questionable.

>> The Linux Kernel has a number of features that address these
>> issues for itself, and it would take work to make this fly
>> for standard userspace code too.
>
>I thought the kernel just breaks internal things all the
>time.  Are you talking about the API between kernel and
>userspace?

No, the userspace API/ABI (syscalls) is not touched; I do mean the
kernel<->kmodule interface. It does not break, it just changes. And
yes, it is like bumping the 'current' number again and again, but
modversions (see reply to Ralf or your nearest modversions-enabled
/lib/modules) allows a longer lifespan.

There is a slight difference compared to glibc's fgets@@GLIBC_2.1
however; the current kmodversions would still only allow one instance
of fgets, albeit guarded against a wrong one.