You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the development cycle of Snapcraft 3.4 we ran into a scenario where certain binaries started to fail after patched with patchelf 0.10 in certain architectures like i386 and ppc64le. In this situation patchelf 0.9 worked correctly, and a bisection told us the offending commit is c4deb5e. However, it seems to be a bad interaction between this patch and one or more of the preceding commits, since just applying c4deb5e over 0.9 (along with a couple of other cherry-picked patches) won't cause patchelf to fail.
At the moment the only known failing binary is the apt-get http helper. Here is the diff between the good and bad headers and section to segment mappings:
The problem was indeed caused by c4deb5e but I confirm that commit 1cc234f in Ed Bartosh's patchelf tree (which was also part of our small collection of cherry-picked patches) fixes the problem in 0.10. It's in PR #127.
During the development cycle of Snapcraft 3.4 we ran into a scenario where certain binaries started to fail after patched with patchelf 0.10 in certain architectures like i386 and ppc64le. In this situation patchelf 0.9 worked correctly, and a bisection told us the offending commit is c4deb5e. However, it seems to be a bad interaction between this patch and one or more of the preceding commits, since just applying c4deb5e over 0.9 (along with a couple of other cherry-picked patches) won't cause patchelf to fail.
At the moment the only known failing binary is the apt-get http helper. Here is the diff between the good and bad headers and section to segment mappings:
The text was updated successfully, but these errors were encountered: