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. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
