Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glibc checkoutScript fails on rebuild #180

Closed
tu-maurice opened this issue Dec 5, 2023 · 2 comments
Closed

glibc checkoutScript fails on rebuild #180

tu-maurice opened this issue Dec 5, 2023 · 2 comments

Comments

@tu-maurice
Copy link
Contributor

I am building the glibc recipe for my target rootfs, but everytime I run bob build ... again it fails with the following error. For now I'm deleting work/libs/glibc/src as a workaround, which does cause a new checkout, but not a new build.

[   7] CHECKOUT  libs::glibc - work/libs/glibc/src/1/workspace 
[   7] |libs::glibc| Patch was (partially) squashed? Trying to recover...
[   7] |libs::glibc| Step failed with return status 1; Command: patch -p $p -F 0 -f < $i
[   7] |libs::glibc| Call stack (most recent call first)
[   7] |libs::glibc|     #0: Class  patch, layer basement, line 42, in patchApplySeries
[   7] |libs::glibc|     #1: Recipe libs::glibc, layer basement, line 1, in main

My guess is bob tries to run the checkoutScript again on sources where the checkoutScript was already executed?

@jkloetzke
Copy link
Member

There are not many reasons why the checkoutScript will run again for fixed packages. This is rather unusual. I'm wondering why this is the case for you. Did you update glibc and removed the digestSHA256? It looks like the tar file was extracted again (and squashed the patch) which should not happen.

Anyway, the real culprit is the patch class that cannot cope with the fact when some or all of it's modifications were reverted. Plus the fact that the $<<glibc/*.diff>> syntax concatenates all files which leads to additional problems when multiple patches patch the same file. See #55 for some similar issue.

@tu-maurice
Copy link
Contributor Author

I did neither of those things. I also keep deleting the source directory I mentioned above. However I do build 2 glibcs, one for the gcc-native to look at during compilation and one for the target rootfs, I have yet to find out how to tell bob to reuse the first glibc.

jkloetzke added a commit to jkloetzke/basement that referenced this issue Mar 10, 2024
Each applied patch is tracked individually. This has the benefit of
being able to handle situations where multiple patches touch the same
file.

Also remove the check if the patch is still applied. This proved to be
unreliable, especially if multiple patches touch the same file. We now
solely rely on the tracked applied patches and compare them to the
desired ones. If they match, the class will assume the patch is still
applied.

Fixes BobBuildTool#55. Fixes BobBuildTool#180.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants