Re: kdev-python in KDevelop 5.6.0

Francis Herne <[email protected]> Wed, 07 Oct 2020 18:02:47 +0100
Newsgroups	gmane.comp.kde.devel.kdevelop
Message-ID	<4727109.3MsxUlN34N@cleator>
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
signature.asc (application/pgp-signature, 488 B)