Do not let libtool stage libc6-dev's libm and libc - #296
Conversation
|
Could also be related to #294? |
|
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. |
|
@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. |
Libtool pulls libc6-dev but no libc6, which causes libc.so to be staged as a broken symlink, as libc.so.6 is missing, which causes the dynamic link step of gtk4 to fail, which causes a static link to be attempted, which also fails. Fixes ubuntu#240.
73d704d to
385bffb
Compare
sergio-costas
left a comment
sergio-costas
left a comment
There was a problem hiding this comment.
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 |
|
I'm sure we will drop this once #294 lands but meanwhile this well unblocks Risc-V and Aarch32. |
|
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 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 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. |
|
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 |
|
In this discussion it can be easy to conflate two cases:
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 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/. |
|
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 Maybe we should move this discussion to #294... |
On riscv64, the build used to fail with: ``` :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__frexp' :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__ldexp' :: [ +2 ms] clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` A first solution to the problem was to stage `libc6` package, but it was not a good solution as it led to runtime issue (not being able to start the installer). The reason for that issue is the fact that libm on riscv64 uses __frexp and others as links to libc, contrary to amd64 where those symbols are only present in libc. Some packages in the snap were pulling static versions of those libraries (libc.a, libm.a) and the linker tried to statically link to libm.a which was missing those symbols as they were dynamically pointing to the libc.so ones. The right solution to that issue seems to be making sure that we don't stage libc.a/libm.a/libc.so/libm.so on riscv64. This commits removed the previously staged-package libc6 and instead uses the previously described solution of not staging the libc/libm files at all. See also: - ubuntu/gnome-sdk#240 - ubuntu/gnome-sdk#294 - ubuntu/gnome-sdk#296
On riscv64, the build used to fail with: ``` :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__frexp' :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__ldexp' :: [ +2 ms] clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` A first solution to the problem was to stage `libc6` package, but it was not a good solution as it led to runtime issue (not being able to start the installer). The reason for that issue is the fact that libm on riscv64 uses __frexp and others as links to libc, contrary to amd64 where those symbols are only present in libc. Some packages in the snap were pulling static versions of those libraries (libc.a, libm.a) and the linker tried to statically link to libm.a which was missing those symbols as they were dynamically pointing to the libc.so ones. The right solution to that issue seems to be making sure that we don't stage libc.a/libm.a/libc.so/libm.so on riscv64. This commits removed the previously staged-package libc6 and instead uses the previously described solution of not staging the libc/libm files at all. See also: - ubuntu/gnome-sdk#240 - ubuntu/gnome-sdk#294 - ubuntu/gnome-sdk#296
On riscv64, the build used to fail with: ``` :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__frexp' :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__ldexp' :: [ +2 ms] clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` A first solution to the problem was to stage `libc6` package, but it was not a good solution as it led to runtime issue (not being able to start the installer). The reason for that issue is the fact that libm on riscv64 uses __frexp and others as links to libc, contrary to amd64 where those symbols are only present in libc. Some packages in the snap were pulling static versions of those libraries (libc.a, libm.a) and the linker tried to statically link to libm.a which was missing those symbols as they were dynamically pointing to the libc.so ones. The right solution to that issue seems to be making sure that we don't stage libc.a/libm.a/libc.so/libm.so on riscv64. This commits removed the previously staged-package libc6 and instead uses the previously described solution of not staging the libc/libm files at all. See also: - ubuntu/gnome-sdk#240 - ubuntu/gnome-sdk#294 - ubuntu/gnome-sdk#296
On riscv64, the build used to fail with: ``` :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__frexp' :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__ldexp' :: [ +2 ms] clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` A first solution to the problem was to stage `libc6` package, but it was not a good solution as it led to runtime issue (not being able to start the installer). The reason for that issue is the fact that libm on riscv64 uses __frexp and others as links to libc, contrary to amd64 where those symbols are only present in libc. Some packages in the snap were pulling static versions of those libraries (libc.a, libm.a) and the linker tried to statically link to libm.a which was missing those symbols as they were dynamically pointing to the libc.so ones. The right solution to that issue seems to be making sure that we don't stage libc.a/libm.a/libc.so/libm.so on riscv64. This commits removed the previously staged-package libc6 and instead uses the previously described solution of not staging the libc/libm files at all. See also: - ubuntu/gnome-sdk#240 - ubuntu/gnome-sdk#294 - ubuntu/gnome-sdk#296
On riscv64, the build used to fail with: ``` :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__frexp' :: [ +2 ms] /usr/bin/ld: plugins/handy_window/libhandy/libhandy_flutter.so: undefined reference to `__ldexp' :: [ +2 ms] clang++: error: linker command failed with exit code 1 (use -v to see invocation) ``` A first solution to the problem was to stage `libc6` package, but it was not a good solution as it led to runtime issue (not being able to start the installer). The reason for that issue is the fact that libm on riscv64 uses __frexp and others as links to libc, contrary to amd64 where those symbols are only present in libc. Some packages in the snap were pulling static versions of those libraries (libc.a, libm.a) and the linker tried to statically link to libm.a which was missing those symbols as they were dynamically pointing to the libc.so ones. The right solution to that issue seems to be making sure that we don't stage libc.a/libm.a/libc.so/libm.so on riscv64. This commits removed the previously staged-package libc6 and instead uses the previously described solution of not staging the libc/libm files at all. See also: - ubuntu/gnome-sdk#240 - ubuntu/gnome-sdk#294 - ubuntu/gnome-sdk#296
3 participants
Closes #240.