ubuntu
SDK: Fix so libraries dangling symlinks
libraries .so files provided by -dev packages normally point to the versioned so file, but if these files are provided by the core snap or another base snap then we should instead use them, if they're not provided by the SDK itself.
So, ensure that all the symlinks in the lib directory are actually pointing to a library file, trying to resolve them with the core-provided libraries as first try.
This fixes the compile issue we have with gnome-boxes as per the linking issues:
2025-04-21 20:49:32.887 :: /snap/gnome-46-2404-sdk/current/usr/bin/ld: /snap/gnome-46-2404-sdk/current/usr/lib/x86_64-linux-gnu/libpciaccess.a(linux_sysfs.o): warning: relocation against `stderr@@GLIBC_2.2.5' in read-only section `.text'
2025-04-21 20:49:32.887 :: /snap/gnome-46-2404-sdk/current/usr/bin/ld: /snap/gnome-46-2404-sdk/current/usr/lib/x86_64-linux-gnu/libpciaccess.a(common_device_name.o): in function `populate_vendor':
2025-04-21 20:49:32.887 :: (.text+0x18d): undefined reference to `gzopen'
2025-04-21 20:49:32.887 :: /snap/gnome-46-2404-sdk/current/usr/bin/ld: (.text+0x1bc): undefined reference to `gzgets'
2025-04-21 20:49:32.887 :: /snap/gnome-46-2404-sdk/current/usr/bin/ld: (.text+0x394): undefined reference to `gzclose'
2025-04-21 20:49:32.888 :: /snap/gnome-46-2404-sdk/current/usr/bin/ld: (.text+0x420): undefined reference to `gzopen'
2025-04-21 20:49:32.888 :: /snap/gnome-46-2404-sdk/current/usr/bin/ld: /snap/gnome-46-2404-sdk/current/usr/lib/x86_64-linux-gnu/libpciaccess.a(linux_sysfs.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
This fixes also these other cases:
2025-04-21T19:14:27.7652675Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libBrokenLocale.so
2025-04-21T19:14:27.7655234Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libBrokenLocale.so.1
2025-04-21T19:14:27.7657027Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libBrokenLocale.so.1
2025-04-21T19:14:27.7668303Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libBrokenLocale.so.1
2025-04-21T19:14:27.7670954Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libBrokenLocale.so.1 /root/prime/usr/lib/x86_64-linux-gnu/libBrokenLocale.so
2025-04-21T19:14:27.7682861Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libBrokenLocale.so' -> '/usr/lib/x86_64-linux-gnu/libBrokenLocale.so.1'
2025-04-21T19:14:27.7685855Z :: +
2025-04-21T19:14:27.8632229Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libanl.so
2025-04-21T19:14:27.8645632Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libanl.so.1
2025-04-21T19:14:27.8648639Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libanl.so.1
2025-04-21T19:14:27.8658523Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libanl.so.1
2025-04-21T19:14:27.8676057Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libanl.so.1 /root/prime/usr/lib/x86_64-linux-gnu/libanl.so
2025-04-21T19:14:27.8676810Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libanl.so' -> '/usr/lib/x86_64-linux-gnu/libanl.so.1'
2025-04-21T19:14:27.8679512Z :: +
2025-04-21T19:14:27.9091535Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so
2025-04-21T19:14:27.9097459Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so.0
2025-04-21T19:14:27.9098504Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so.0
2025-04-21T19:14:27.9107874Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so.0
2025-04-21T19:14:27.9111709Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libc_malloc_debug.so.0 /root/prime/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so
2025-04-21T19:14:27.9126662Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so' -> '/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so.0'
2025-04-21T19:14:27.9128331Z :: +
2025-04-21T19:14:27.9381751Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libcrypt.so
2025-04-21T19:14:27.9405472Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0
2025-04-21T19:14:27.9406127Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0
2025-04-21T19:14:27.9407716Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0
2025-04-21T19:14:27.9413478Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0 /root/prime/usr/lib/x86_64-linux-gnu/libcrypt.so
2025-04-21T19:14:27.9427626Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libcrypt.so' -> '/usr/lib/x86_64-linux-gnu/libcrypt.so.1.1.0'
2025-04-21T19:14:27.9428341Z :: +
2025-04-21T19:14:28.2410903Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libmvec.so
2025-04-21T19:14:28.2424731Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libmvec.so.1
2025-04-21T19:14:28.2425665Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libmvec.so.1
2025-04-21T19:14:28.2433988Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libmvec.so.1
2025-04-21T19:14:28.2437987Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libmvec.so.1 /root/prime/usr/lib/x86_64-linux-gnu/libmvec.so
2025-04-21T19:14:28.2448685Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libmvec.so' -> '/usr/lib/x86_64-linux-gnu/libmvec.so.1'
2025-04-21T19:14:28.2451476Z :: +
2025-04-21T19:14:28.2571158Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libnss_compat.so
2025-04-21T19:14:28.2575968Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libnss_compat.so.2
2025-04-21T19:14:28.2576937Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libnss_compat.so.2
2025-04-21T19:14:28.2590023Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libnss_compat.so.2
2025-04-21T19:14:28.2591451Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libnss_compat.so.2 /root/prime/usr/lib/x86_64-linux-gnu/libnss_compat.so
2025-04-21T19:14:28.2603414Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libnss_compat.so' -> '/usr/lib/x86_64-linux-gnu/libnss_compat.so.2'
2025-04-21T19:14:28.2617420Z :: +
2025-04-21T19:14:28.2633341Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libnss_hesiod.so
2025-04-21T19:14:28.2638364Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libnss_hesiod.so.2
2025-04-21T19:14:28.2647972Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libnss_hesiod.so.2
2025-04-21T19:14:28.2651783Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libnss_hesiod.so.2
2025-04-21T19:14:28.2654605Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libnss_hesiod.so.2 /root/prime/usr/lib/x86_64-linux-gnu/libnss_hesiod.so
2025-04-21T19:14:28.2672222Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libnss_hesiod.so' -> '/usr/lib/x86_64-linux-gnu/libnss_hesiod.so.2'
2025-04-21T19:14:28.2674379Z :: +
2025-04-21T19:14:28.2958314Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libpciaccess.so
2025-04-21T19:14:28.2972622Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1
2025-04-21T19:14:28.2973906Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1
2025-04-21T19:14:28.2983570Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1
2025-04-21T19:14:28.2990439Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1 /root/prime/usr/lib/x86_64-linux-gnu/libpciaccess.so
2025-04-21T19:14:28.3002763Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libpciaccess.so' -> '/usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1'
2025-04-21T19:14:28.3006533Z :: +
2025-04-21T19:14:28.3782845Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libresolv.so
2025-04-21T19:14:28.3797871Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libresolv.so.2
2025-04-21T19:14:28.3799269Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libresolv.so.2
2025-04-21T19:14:28.3808636Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libresolv.so.2
2025-04-21T19:14:28.3822038Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libresolv.so.2 /root/prime/usr/lib/x86_64-linux-gnu/libresolv.so
2025-04-21T19:14:28.3826156Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libresolv.so' -> '/usr/lib/x86_64-linux-gnu/libresolv.so.2'
2025-04-21T19:14:28.3827052Z :: +
2025-04-21T19:14:28.4324023Z :: ++ readlink /root/prime/usr/lib/x86_64-linux-gnu/libthread_db.so
2025-04-21T19:14:28.4338047Z :: + core_lib=/snap/core24/current/usr/lib/x86_64-linux-gnu/libthread_db.so.1
2025-04-21T19:14:28.4339762Z :: + realpath --canonicalize-existing /snap/core24/current/usr/lib/x86_64-linux-gnu/libthread_db.so.1
2025-04-21T19:14:28.4351158Z :: /snap/core24/888/usr/lib/x86_64-linux-gnu/libthread_db.so.1
2025-04-21T19:14:28.4355710Z :: + ln -svf /usr/lib/x86_64-linux-gnu/libthread_db.so.1 /root/prime/usr/lib/x86_64-linux-gnu/libthread_db.so
2025-04-21T19:14:28.4368474Z :: '/root/prime/usr/lib/x86_64-linux-gnu/libthread_db.so' -> '/usr/lib/x86_64-linux-gnu/libthread_db.so.1'
2025-04-21T19:14:28.4381415Z :: +
UDENG-6680
Before merging this... what happens with the review tools? It seems that they do ensure that no soft link points outside the snap...
So maybe the solution is to add all those links in Core24...
Oh I didn't check review tools output... But if they don't work with this, then... The only option would be to copy the actual libraries in the sdk too and ensure that they don't get removed as duplicate...
Oh I didn't check review tools output... But if they don't work with this, then... The only option would be to copy the actual libraries in the sdk too and ensure that they don't get removed as duplicate...
I still think that they should go in Core24: if you think about it, it IS being used to compile, when you build any snap...
I really dislike having duplicated libraries.
Yeah, but I feel that's the way... Since I'm pretty sure that core doesn't want to include dev packages contents.
While us being a dev sdk we need to provide everything required to build.
So if core is missing something, we have to.
Implies more maintenance though, I agree.
So... do we copy the required files from CoreXX into the right folder wherever there is a dangling pointer...?
AFAIK is the only way we can... And ensure they get not deleted by duplicates checking tool
Moving from #296:
The point is that if the SDK requires something in the CoreXX to be built, it must add the corresponding -dev package in
build-packagestoo, not build itself from scratch, and those soft links will not be instagebut in the build system. Instagewill be only pieces installed due to dependencies, and those must be removed.
What do you mean with "build itself from scratch", what is "itself"? In Libtool's case the -dev package (libc6-dev) was added to build-packages.
What do you mean with "build itself from scratch", what is "itself"? In Libtool's case the -dev package (libc6-dev) was added to build-packages.
Exactly: since Core24 doesn't have the soft link libBrokenLocale.so pointing to libBrokenLocale.so.1, then the SDK snap has to install libc6-dev, which is the one that creates it, instead of building libc6 itself from sources to have that link.
In fact... why is libpciaccess in gnome-46-2404-sdk if it is already in Core24?
Ok, confirmed my suspicions: just by removing the broken soft link, the libpciaccess.a file, and (this is the key point) the pciaccess.pc file, all from the `gnome-46-2404-sdk' snap, building gnome-boxes works as expected.
The problem is that the pciaccess.pc file in the gnome-46-2404-sdk snap takes precedence over the one installed from the build-packages, and they try to compile against a library in the snap. We removed the duplicated libraries (because they are already in Core24), but didn't remove the .pc file, and that is what is breaking everything.
So if we remove a library in the gnome SDK because it is already in Core24, we must also remove the corresponding .pc file to avoid this.
Exactly: since Core24 doesn't have the soft link libBrokenLocale.so pointing to libBrokenLocale.so.1, then the SDK snap has to install libc6-dev, which is the one that creates it, instead of building libc6 itself from sources to have that link.
That makes sense. We never built libc6 though.
@3v1n0 So, in my opinion, the true solution is to find which .pc file correspond to each duplicated library in Core24 and remove it. It's not easy, I now, but with some python magic... ;-)
In fact... just checking the "Libs" and "Libs.private" parts should be enough to know which libraries are affected by a .pc file, so if they aren't available in gnome-XX-YY-sdk, then that .pc file can be removed.
@3v1n0 So, in my opinion, the true solution is to find which .pc file correspond to each duplicated library in Core24 and remove it. It's not easy, I now, but with some python magic... ;-)
Well, I'm unsure either... These are build dependencies of dependencies we have in the SDK IIRC, I mean if any of these libraries headers/pc files are part of the gnome-sdk, then we should provide them too.
For example for the pciaccess one:
❯ apt-cache rdepends libpciaccess-dev
libpciaccess-dev
Reverse Depends:
libdrm-dev
xserver-xorg-dev
xserver-xorg-dev
xserver-xorg-dev
libdrm-dev
xserver-xorg-dev
xserver-xorg-dev
libdrm-dev
xserver-xorg-dev
Since we have stage packages such as libdrm-dev, then we need to also fully stage their dependencies. And we were kinda doing it, but then we end up removing the duplicates that are part of core wrongly.
It's fine to remove them from the runtime snap, but not from the sdk.
But then, what we have to do is to ensure that using the gnome SDK requires to install the corresponding stage-packages that are provided by CoreXX.
Anyway... you don't necessarily need those dependencies to build something with those libraries... and if you need them for whatever reason, the build error will tell you what you have to add to the build-packages. And removing the pkgconfig files in the SDK will make that work.
Ok, let's take a step back and see the whole thing... Core24 (and other Cores) are built just by "dumping" an Ubuntu base system, as seen here: https://github.com/canonical/core-base/blob/277049e8bf67fdeadb9afe92428220e02cf95142/snapcraft.yaml#L13
The point is that, when building new snaps against CoreXX, the development files aren't there. Where are they get? And the answer is that snapcraft must automagically download them from .deb packages, things like libc6-dev, build-essential, make, pkg-config...
Also, there is a list of packages that must not be staged, because they are known to be included from Core... https://github.com/canonical/snapcraft/blob/0157e5b15e66af34a4b12d397e5f56a30eebb13d/snapcraft_legacy/internal/repo/_deb.py#L51
But all that I found at this point is only available in legacy, so for new snaps it must be done somewhere else.
So the point, in my opinion, is to find where those required -dev files are defined, and send a patch for snapcraft to add libpciaccess0 and libcrypt1 to the list of exceptions, and to include libpciaccess-dev and libcrypt-dev, because those two are already in Core24.
Ok, it seems that the list of blocked packages is in craft-parts: https://github.com/canonical/craft-parts/blob/1f163c0ec0691182cf08da52cc1cfc7160618241/craft_parts/packages/deb.py#L57-L283 So... Should we add there libpciaccess0 and libcrytp1?
Also, in matrix https://matrix.to/#/!GGqzbFAUQprdPgYYCM:ubuntu.com/$bfuUc0FUzOVXuLGDn6RnlWXLWYqYzAVwfWdhF-qZRYE So it seems that no deb file is installed by snapcraft; instead, any development package seems to have to be installed by the snap, which is consistent with gnome-46-2404-sdk installing gcc, pkg-config, g++, clang...
Interesting thing: that list of packages in craft-parts is used for Core20 and previous; for others, it takes the list of packages installed in CoreXX and filters them https://github.com/canonical/craft-parts/blob/44aa6508874e8f4d022f13bd5760776ef987a79e/craft_parts/packages/deb.py#L362
Which means that libpciaccess0 will never be staged because it's already in Core24...
As discussed in previous days, we should provide all the build-dependencies of our build-dependencies in the SDK, given that there's no way to symlink core paths we've to duplicate these core files in the SDK (for the runtime, I'll propose another patch to filter duplicates out)
The list of newly added files to the SDK is limited to:
Only in squashfs-root/usr/lib/x86_64-linux-gnu: gconv
Only in squashfs-root/usr/lib/x86_64-linux-gnu: ld-linux-x86-64.so.2
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libanl.so.1
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libBrokenLocale.so.1
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libc_malloc_debug.so.0
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libcrypt.so.1
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libcrypt.so.1.1.0
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libc.so.6
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libdl.so.2
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libmemusage.so
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libm.so.6
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libmvec.so.1
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libnsl.so.1
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libnss_compat.so.2
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libnss_dns.so.2
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libnss_files.so.2
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libnss_hesiod.so.2
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libpciaccess.so.0
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libpciaccess.so.0.11.1
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libpcprofile.so
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libpthread.so.0
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libresolv.so.2
Only in squashfs-root/usr/lib/x86_64-linux-gnu: librt.so.1
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libthread_db.so.1
Only in squashfs-root/usr/lib/x86_64-linux-gnu: libutil.so.1
Only in squashfs-root/usr: lib64
But at least now we have all the dev files without dead links.
Not sure if using bindings could have helped to avoid duplicates on core, but that would imply having a manually managed list of libraries to maintain.
It seems that krb5-multidev is either required, o removing the dangling pointer /usr/lib/x86_64-linux-gnu/mit-krb5/libgssapi_krb5.so is needed...
It seems that krb5-multidev is either required, o removing the dangling pointer
/usr/lib/x86_64-linux-gnu/mit-krb5/libgssapi_krb5.sois needed...
It looks a bit out of place here TBH. @nteodosio do you know what could have pulled it in?
Thanks, with the last commit we went from
/root/prime/usr/lib/x86_64-linux-gnu/libcom_err.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libcrypt.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libelf.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libffi.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libk5crypto.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libkrb5support.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libtirpc.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/mit-krb5/libgssapi_krb5.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/mit-krb5/libk5crypto.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/mit-krb5/libkrb5support.so: dangling symlink!
down to
/root/prime/usr/lib/x86_64-linux-gnu/libk5crypto.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libffi.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libelf.so: dangling symlink!
/root/prime/usr/lib/x86_64-linux-gnu/libkrb5support.so: dangling symlink!
So still needing libffi8, libelf1t64, libk5crypto3 and libkrb5support0.
Those are now gone but eventually more popped up.
:: /root/prime/usr/lib/x86_64-linux-gnu/libcrypt.so: dangling symlink!
:: /root/prime/usr/lib/x86_64-linux-gnu/libcom_err.so: dangling symlink!
:: /root/prime/usr/lib/x86_64-linux-gnu/libtirpc.so: dangling symlink!
Probably something needs to be re-worked, we can't go whack-a-moling ad infinitum.
Probably something needs to be re-worked, we can't go whack-a-moling ad infinitum.
Well, pkg-config can help us with that... We should just follow the whole dependency chain.