[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
> >>  (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.


> >- 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]