kdev-python in KDevelop 5.6.0

Francis Herne mail at flherne.uk
Wed Oct 7 18:02:47 BST 2020


On Wednesday, 7 October 2020 17:50:54 BST Sven Brauch wrote:
> Hi,
> 
> On 2020-10-06 12:34, Francis Herne wrote:
> > Someone pointed me athttps://appimage-builder.readthedocs.io/en/latest/
> > index.html , which removes the need for building on ancient distro
> > releases
> > altogether
> 
> I doubt that. There is a very real effect of building on the old distro:
> you build against an old glibc binary interface, which depends on an old
> kernel binary interface. glibc is guaranteed backwards compatible, but
> not forward compatible.
> 
>   * You obviously cannot ship the kernel with the AppImage.
>   * For this reason, you cannot ship glibc either, because a new glibc
>     might use interfaces of the kernel that don't exist yet on the
>     user's older machine.
>   * Thus, all your userspace libraries must not use any of the new glibc
>     functionality. The only way to guarantee that I know of is to build
>     against the old interface.
> 
> This problem isn't going away without a lot of effort from a lot of
> parties, I think. It isn't solvable by just shipping the right set of
> libraries, you actually need builds of the libraries that fulfill this
> condition.
> 
> Greetings!

Hi Sven,

I spoke with one of the AppImage developers responsible for this, it's 
definitely a thing. ;-)

glibc has very conservative kernel dependencies (the current version requires 
3.2, which is years older than any still-maintained distro), so that isn't a 
problem.

More of an issue with shipping glibc in an AppImage is that it would break on 
*newer* distros, since some system libs do have to be dynamically linked-in 
and those might use symbols not yet available in the bundled libc. This is why 
most AppImages currently avoid including libc.

The appimage-builder tool packages a linking helper that determines at runtime 
which glibc version is newer, the system's or the bundled one, and uses that. 
I believe this also applies to a few other core libraries.

Anyway, I don't plan to use it just now, so this is a bit of a tangent. :p

-Francis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20201007/100506e6/attachment.sig>


More information about the KDevelop-devel mailing list