[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Better soname linking
From: |
Kurt Roeckx |
Subject: |
Re: Better soname linking |
Date: |
Wed, 4 Nov 2009 21:05:15 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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