Do not let libtool stage libc6-dev's libm and libc

[nteodosio]

Closes #240.

[3v1n0]

Could also be related to #294?

[nteodosio]

The root cause of the problem here is that libc.so is staged from libtool part but is dangling. The core snap provides libc.so.6 so indeed this is a case perfectly fitting the description of that merge request, so it should solve the problem too.

We might nonetheless be more selective when staging libtool (maybe other parts too). A snap packed with just that part is 56 MB in size.

[nteodosio]

@xypron confirmed this merge request fixes the build for Risc-V, and I confirmed that it fixes Armhf too, so this is good to go.

[sergio-costas]

It makes sense: those two libraries must be in CoreXX, so it makes no sense to have them here too.

[3v1n0]

It makes sense: those two libraries must be in CoreXX, so it makes no sense to have them here too.

No wait... Again those are dev libraries, so they should not be in core (and they are not) but in a fixed way, in the sdk.

We should revert this as part of the final fix for #294

[nteodosio]

I'm sure we will drop this once #294 lands but meanwhile this well unblocks Risc-V and Aarch32.

[sergio-costas]

Ok, let's rewind a little bit... the point is that CoreXX has libraries A, B, C... but not the soft links required to build code with them. So, where are those soft links? I presume that they should be in the build system used by snapcraft, and thus, they must had been installed using a build-packages statement.

This means that we must presume that CoreXX is ALWAYS built exclusively with .deb packages, and that no part of CoreXX is built using sources, because if sources are used, then we wouldn't be able to compile against the version in CoreXX, only against the version in base ubuntu because, again, the soft links to the libraries aren't in CoreXX, but must be installed from .deb files using a build-packages statement in the snapcraft file.

So... this means that we should remove all the soft links in Gnome-SDK to libraries that are already in CoreXX, both the "normal soft links" (xxxxx.so.Y) and the "compiler soft links" (xxxx.so), along with the corresponding library (xxxx.so.X.Y), and also remove any pkg-config file for those duplicated libraries to ensure that the build process uses the ones provided by the installed .deb packages.

[sergio-costas]

And thus, if a soft link to a library in CoreXX is missing when trying to compile it, then it's the responsibility of the builder to add the corresponding .deb file to the build-packages statement in the snapcraft.yaml file.

[nteodosio]

In this discussion it can be easy to conflate two cases:

1. To un-prime links that also appear in the base snap, so that it does not affect consumers of the snap; and
2. To un-stage links that also appear in the base snap, so that it does not affect other parts of the SDK snap itself during the build of the SDK snap.

remove all the soft links in Gnome-SDK to libraries that are already in CoreXX

I'm pretty sure you are talking about 1, as we cannot afford 2 because the building of the SDK components themselves require such libraries, and, as surely no one will dispute, we cannot prohibit a part in the SDK snap to use a library that the base snap ships.

This merge request is about 2: Unstaging libc.so so that it does not contaminate the build of other parts in this very snap —­ more specifically: The Libtool part's build produced side-effects that affected Gtk4 part's build, insofar as it staged a broken .so link to a path that is set in LD_LIBRARY_PATH in all parts' environments, and Gtk4 is set to build after Libtool.

Yes, that also causes 1 because coincidentally libc.so will not be primed either; the new SDK revisions won't have it packed. But if we really wanted, we could prime libc.so (say, in a final part) in this snap again. There is just no point in doing that because right here, right now, libc.so is a broken link. When we maybe land #294, this may be different, but, at the present HEAD, libc.so is not only pointless, but harmful (as we saw for Risc-V and Aarch32 builds of this snap), and can never ever be useful for any other snap build using the SDK.

Back to the general proposal 1, I think that makes sense. But I fear many snaps will suddenly start failing to build, and thinking of a random maintainer's perspective, who is not aware of this discussion, it may be overwhelming. Moreso as this snap is prefixed with "gnome" and yet provides many libraries that are merely related to, but not at all owned by, Gnome, so when a maintainer bumps a minor version release and the build is suddenly now failing against, say, libxkbcommon, they might have a dull time tracing this.

So although I think the change would be logically right and reasonable, I'm not sure about it when I weight that against https://xkcd.com/1172/.

[sergio-costas]

I was really talking about #294. The point is that if the SDK requires something in the CoreXX to be built, it must add the corresponding -dev package in build-packages too, not build itself from scratch, and those soft links will not be in stage but in the build system. In stage will be only pieces installed due to dependencies, and those must be removed.

Maybe we should move this discussion to #294...