On Wed, Nov 04, 2009 at 08:42:00PM +0100, Jan Engelhardt wrote: > > On Wednesday 2009-11-04 20:22, Kurt Roeckx wrote: > >On Sun, Oct 25, 2009 at 03:00:27PM +0100, Jan Engelhardt wrote: > >> > >> program: unknown symbol api23_function in libfoo.so.22 > >> (or similar wording) > > > >In Debian-based systems there we have 2 solutions for that: > >- Make sure that the Depends field always has a version of > > >= 23 > > That would be manual work, would not it? > And manual work tensd to be forgotten sometimes.
Yes. > >- Look at the symbols that got used, and only depend on > > >= 23 when symbols from that version are used. > > This sounds like the nicest approach, but how would you figure > out what symbols belong to 23 and which to 22? This is also "manual" work. It keeps a list in the package with the symbols. Next time you build the package it compares the list of symbols with those in the file and can generate an error + diff in case of changes. And then you update the file. > 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. > 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? Kurt _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
