Function that returns the GLIBC_ version of a file or directory

[probonopd]

I need a function that returns the highest GLIBC_ version needed of a file or directory.

The equivalent of

https://github.com/AppImage/pkg2appimage/blob/bb64b4389123a1e0c0bb10b030140c27b59010fb/functions.sh#L134-L139

[probonopd]

If I need to resort to doing it myself it will be ugly, so better keep you C++ knowing experts assigned @TheAssassin

[TheAssassin]

This just generates double spam mails. Please don't assign anything until it is being worked on. It doesn't make a difference if all or none issues are assigned to you.

[probonopd]

We need a system where we can prioritize things, so that we can move this up. As long as no one is assigned, no one will start working on it...

[TheAssassin]

Assignments aren't a way of "sorting things by priority", we have labels for this.

This has by the way no priority in the current rewrite.

[azubieta]

@probonopd is this going to show the GLIBC_ required by the AppImage "runtime" or by the binaries at the payload?

[probonopd]

This shall return the version of GLIBC that is needed to run the binaries in a given directory (if a directory is supplied as an argument, or the version of GLIBC that is needed to run an ELF (if the path to an ELF is supplied as an argument)

[azubieta]

@probonopd I have some dubs it this should be part of libappimage would you please provide a full use case?

[probonopd]

Here are some use cases:

• appimagetool should write the minimal required glibc version into a X-AppImage-... key
• appimagetool should print a warning if the glibc that the AppDir requires is "too new"
• Tools like AppImageLauncher could display an error dialog box if the glibc needed by an AppImage is newer than what the system provides

and so on.

[azubieta]

Thanks @probonopd. Right now libappimage is about reading AppImage files. We deal with AppDirs in linuxdeploy (it has some kind of pseudo lib there). Therefore this could be a feature for linuxdeploy or for appimmagetool itself. @TheAssassin have you considered making a real library of it? Like to use it in appimagetool?

[TheAssassin]

@TheAssassin have you considered making a real library of it?

Define it. There already is a liblinuxdeploy (it's been designed from scratch like that), linuxdeploy is just a frontend of it. linuxdeploy-plugin-qt for instance is a user of liblinuxdeploy.

[azubieta]

I should had say "it is some kind of" instead of "it has".

[probonopd]

Right now libappimage is about reading AppImage files

True... I didn't see it this way, I thought "libappimage is the library for everything that has to do with AppDirs and AppImages". Wouldn't that be simpler, actually?

[azubieta]

As AppDirs and AppImages have a lot in common, we could perfectly fit the AppDir logic on it. But also consider that AppDir is not only an AppImage specific topic that's why @TheAssassin didn't make linuxdeploy to exclusive to make AppImages.

[TheAssassin]

I disagree about AppDirs, that's none of the concerns of libappimage. I think that libappimage shall be for working with AppImages only.

Any appimagetool-specific code should in the end be moved to AppImageKit. My ultimate goal is to properly rewrite appimagetool with an architecture like linuxdeploy, i.e., create a libappimagekit and build appimagetool as a frontend for it. This architecture turned out to be highly beneficial for the development of linuxdeploy, as it allows for proper testing and promotes principles like loose coupling between components.

[TheAssassin]

So, in the end:

• libappimage: read, mount and integrate AppImages
• libappimagekit: make AppImages
• liblinuxdeploy: work with AppDirs

[probonopd]

Can't we merge libappimage and libappimagekit? What would be the downside? I don't want this to become ever more complex, with ever more parts...

[probonopd]

rewrite

I'm increasingly allergic to this word. "Gradually refactor" strongly perferred. One commit at a time, in the master branch.

[azubieta]

Can't we merge libappimage and libappimagekit? What would be the downside?

It's about binaries size. Desktop apps using libappimage will not care about creation.

---

Edit:

But, if we reduce the concept of AppImage creation to just comprising the AppDir and appending a runtime to it. They could live in the same repository and be two different binaries as they share the same dependencies.

[TheAssassin]

There is no libappimagekit yet. As you know, AppImageKit's code base is overly complex and has many annoyances in it. That's due to the history of its development. This can't be fixed.

I also had rather started on a clean branch with the libappimage rewrite, but @azubieta did it on master. That worked, but we still have some old code in there.

"Gradually refactor" strongly perferred

This combination of words is IMO the source of evil. AppImageKit's code must be rewritten, period. As we started to do things in C++, that's anyway necessary. There's no reason to intentionally mix some of the old annoying code with the clean and fresh code that will be created.

It's about binaries size. Desktop apps using libappimage will not care about creation.

That's wrong. You can modularize libraries. Call it a framework if you want to. liblinuxdeploy is split into multiple modules, too.

We can surely put all of the new appimagetool specific code into the same repo as libappimage.

Edit: in the end, making AppImages is a lot less of an issue than desktop integration. So that's less of an issue.

[probonopd]

appimagetool is working entirely fine as-is in my view, I have no fundamental issues with it. But I think it should refuse to build AppImages that need a too new glibc. Never touch a running system ;)

[azubieta]

There's no reason to intentionally mix some of the old annoying code with the clean and fresh code that will be created.

There is one shipping often

[TheAssassin]

There is one shipping often

That doesn't apply to our situation for obvious reasons.

[darealshinji]

Here's an exampe how to get the highest GLIBC version from a directory: https://github.com/darealshinji/code-snippets/blob/master/glibc-version.c https://gist.github.com/darealshinji/c3ece5ec7d3ac580793c578928bee0a6

It's Public Domain.

[probonopd]

Here it is in shell using readelf:

find squashfs-root -type f -exec readelf -s {} \; 2>/dev/null | grep 'GLIBC_[0-9]' | cut -d "@" -f 2 | cut -d " " -f 1 | sort -r -V | uniq | head -n 1

[darealshinji]

If you still need tools or code to parse ELF files and you want a permissive license you can take a look at elftoolchain: https://sourceforge.net/p/elftoolchain/code

elfdump/elfdump elfdump/elfdump | grep 'vna_name: GLIBC_[0-9]'

On my system it needs pmake to compile: pmake -C common && pmake -C libelf && pmake -C libelftc && pmake -C elfdump