Hi,
Recent AppImage build (https://download.opensuse.org/repositories/home:/linuxbuild/AppImage/hw-probe-0-Build138.1.glibc2.17-x86_64.AppImage) triggers such error on start.
chmod +x ./hw-probe-0-Build138.1.glibc2.17-x86_64.AppImage
./hw-probe-0-Build138.1.glibc2.17-x86_64.AppImage --appimage-extract
error while loading shared libraries: liblzo2.so.2: cannot open shared object file: No such file or directory
Previous builds do not trigger such error.
How to remove liblzo2 dependency?
Environment: Ubuntu 12.
@adrianschroeter looks like you're building the AppImage runtime against shared libraries. liblzo2 is most likely pulled in by a wrongly built distro provided libsquashfuse.
Can you please either make it a completely static build or use the upstream runtime provided in the releases section? This is a rather major issue.
@adrianschroeter looks like you're building the AppImage runtime against shared libraries. liblzo2 is most likely pulled in by a wrongly built distro provided libsquashfuse.
Can you please either make it a completely static build or use the upstream runtime provided in the releases section? This is a rather major issue.
It's a default build by openSUSE build service (OBS): https://build.opensuse.org/
It's triggered automatically by changes in my appimage.yml.
Should I report this to OBS maintainers?
I have adapted this patch now for static linking:
https://build.opensuse.org/package/rdiff/OBS:AppImage/AppImageKit?linkrev=base&rev=1659
Can you rebuild and retry please?
Now it requires GLIBC_2.17 instead of GLIBC_2.14 ( It is missed on the Ubuntu 12.
Thank you.
Now it requires
Which component requires GLIBC_2.17 instead of GLIBC_2.14 now?
2.17 is from 2012, so it should work on all still-supported versions of Ubuntu. Do you really need _that_ old an Ubuntu release?
also our old enviroment based on SLE 12 / Leap 42.x was using 2.19 already btw . ... newer default is SLE 15 / Leap 15.x is using glibc 2.26 now (former branched AppImage templates are not affected by this).
Don't ask me how they do it, but libc markers are usually only included for APIs actually used. You can build a runtime on Ubuntu bionic that can run on trusty (if you build your dependencies yourself). The new runtime, if the information provided by @linuxhw is correct (I haven't been able to verify that, since @linuxhw hasn't provided a link to the new AppImage -- please do so!), that's fine for our needs. If the contents don't run on a system newer than CentOS 6, why should the runtime, right?
@TheAssassin
Don't ask me how they do it, but libc markers are usually only included for APIs actually used. You can build a runtime on Ubuntu bionic that can run on trusty (if you build your dependencies yourself). The new runtime, if the information provided by @linuxhw is correct (I haven't been able to verify that, since @linuxhw hasn't provided a link to the new AppImage -- please do so!), that's fine for our needs. If the contents don't run on a system newer than CentOS 6, why should the runtime, right?
Latest AppImage is here: https://download.opensuse.org/repositories/home:/linuxbuild/AppImage/
@probonopd
Now it requires
Which component requires GLIBC_2.17 instead of GLIBC_2.14 now?
2.17 is from 2012, so it should work on all still-supported versions of Ubuntu. Do you really need _that_ old an Ubuntu release?
Execution of the AppImage. By default Ubuntu ships Glibc 2.15, but AppImage requires 2.17 to start due to the error message on start.
@adrianschroeter
also our old enviroment based on SLE 12 / Leap 42.x was using 2.19 already btw . ... newer default is SLE 15 / Leap 15.x is using glibc 2.26 now (former branched AppImage templates are not affected by this).
Do we (users of AppImage) have any benefits from upgrading the build platform? For now I only see reduced number of supported OSes and this prevents me from publishing AppImage updates.
On Mittwoch, 20. November 2019, 05:35:35 CET Linux Hardware Project wrote:
@adrianschroeter
also our old enviroment based on SLE 12 / Leap 42.x was using 2.19 already
btw . ... newer default is SLE 15 / Leap 15.x is using glibc 2.26 now
(former branched AppImage templates are not affected by this).
Do we (users of AppImage) have any benefits from upgrading the build
platform? For now I only see reduced number of supported OSes and this
prevents me from publishing AppImage updates.
You are repackaging some content inside the AppImage apart from
your source, I suppose. So you want to get the latest security fixes
for these, right?
So you don't want to use eg. a openssl or libQt from a not anymore maintained
OS which may have security issues.
You can still build against openSUSE_Leap 42 (which is not maintained anymore)
in the build system if you know what you are doing.
There is also the SLE 12 base, which is similar old (at least in regards of
glibc), but still gets maintenance updates, if you prefer that.
But our default in OBS for new created AppImage packages is the old maintained
openSUSE Leap (which is meanwhile also relative old glibc wise) because you
can easily get the biggest amount of 3rd party packages. eg. all kind versions
of libQt or newer python/ruby/... stacks.
--
Adrian Schroeter adrian@suse.de
Build Infrastructure Project Manager
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
(HRB 247165, AG M眉nchen), Gesch盲ftsf眉hrer: Felix Imend枚rffer
@linuxhw my quick test with appimagelint showed the following results:
> appimagelint hw-probe-0-Build141.1.glibc2.17-x86_64.AppImage
appimagelint.cli[23615] [INFO] Checking AppImage hw-probe-0-Build141.1.glibc2.17-x86_64.AppImage
appimagelint.cli[23615] [INFO] Running check "GNU libc ABI check"
appimagelint.glibc_abi_check[23615] [INFO] detected required version for runtime: 2.17
appimagelint.glibc_abi_check[23615] [INFO] detected required version for payload: 2.17
appimagelint.cache[23615] [INFO] Fetching glibc version data for debian
appimagelint.setup[23615] [INFO] Fetching glibc package versions from Debian sources API
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Debian oldstable (stretch)
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Debian stable (buster)
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Debian testing (bullseye)
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Debian unstable (sid)
appimagelint.cache[23615] [INFO] Fetching glibc version data for ubuntu
appimagelint.setup[23615] [INFO] Fetching glibc package versions from Ubuntu FTP mirror
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu trusty
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu xenial
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu bionic
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu cosmic
appimagelint.glibc_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu disco
appimagelint.cli[23615] [INFO] Running check "GNU libstdc++ ABI check"
appimagelint.glibcxx_abi_check[23615] [INFO] detected required version for runtime: <none>
appimagelint.glibcxx_abi_check[23615] [INFO] detected required version for payload: 3.4
appimagelint.cache[23615] [INFO] Fetching glibcxx version data for debian
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Debian oldstable (stretch)
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Debian stable (buster)
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Debian testing (bullseye)
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Debian unstable (sid)
appimagelint.cache[23615] [INFO] Fetching glibcxx version data for ubuntu
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu trusty
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu xenial
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu bionic
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu cosmic
appimagelint.glibcxx_abi_check[23615] [INFO] [鉁擼 AppImage can run on Ubuntu disco
appimagelint.cli[23615] [INFO] Running check "Icons validity and location check"
appimagelint.icons_check[23615] [INFO] Extracting icon name from desktop file: /tmp/.mount_hw-proZDC0fy/hw-probe.desktop
appimagelint.icons_check[23615] [INFO] Checking resolution of icon: /tmp/.mount_hw-proZDC0fy/hw-probe.png
appimagelint.icons_check[23615] [INFO] [鉁擼 Valid icon in AppDir root
appimagelint.icons_check[23615] [INFO] Checking resolution of icon: /tmp/.mount_hw-proZDC0fy/.DirIcon
appimagelint.icons_check[23615] [INFO] [鉁擼 Valid icon file in .DirIcon
appimagelint.icons_check[23615] [INFO] [鉁擼 Other integration icons valid
appimagelint.cli[23615] [INFO] Running check "Desktop files existence and validity"
appimagelint.desktop_files[23615] [INFO] Checking desktop files in root directory
appimagelint.desktop_files[23615] [INFO] [鉁擼 Exactly one desktop file in AppDir root
appimagelint.desktop_files[23615] [INFO] Checking desktop file /tmp/.mount_hw-prooWV9mR/hw-probe.desktop with desktop-file-validate
appimagelint.desktop_files[23615] [INFO] [鉁擼 All desktop files in AppDir are valid
libc 2.17 is really old and noone using the systems mentioned in the report should experience any compatibility problems. Your AppImage is otherwise okay as well.
As said, at least for libc, if you use only old APIs, there shouldn't be any issues normally.
Closing this one as resolved. Thanks for fixing the runtime build problem so quickly @adrianschroeter.