8378 2015-09-22 21:56:19 +0000 archiver class is broken for gcc packages when using patched sources 2016-01-06 14:40:42 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple VERIFIED FIXED Medium+ normal 2.1 M1 1 alejandro.hernandez alejandro.hernandez benjamin.esquivel bogdanx.a.voiculescu poky.bs.watcher poky.watcher bogdanx.a.voiculescu --- --- No (bug/feature does not impact docs) oldest_to_newest 54496 0 alejandro.hernandez 2015-09-22 21:56:19 +0000 The archiver class is used to obtain the sources used to build the distribution, it has different options; see http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle for more info. When using: ARCHIVER_MODE[src] = "patched" to obtain the patched sources, we obtain an error like the following: ERROR: Command Error: exit status: 1 Output: Applying patch 0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch patching file configure Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file configure.rej Patch 0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch appears to be empty; applied ERROR: Function failed: patch_do_patch This simply states that bitbake tried to apply a patch, but that patch had already been applied so it skips it (which is good), but this still causes the task to fail, hence the build fails too. This is caused because gcc packages use a shared directory for performance and space efficiency (http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#structure-build-work-shared), now, since several packages use the same source, the first task to patch the source will patch it correctly and succeed, but the second one will find an already patched source and produce the error mentioned above. I believe gcc packages were initially not supported by the archiver class for this same reason, it appears to me that using shared states to check whether or not the patches have already been applied is not an option (although I don't know much about SSTATES), since these refer to different tasks for different packages, another option would be to create a specific case to handle gcc packages, perhaps somehow check if the source is already patched and simply return, or do not support gcc packages on the archiver class at all. 54795 1 alejandro.hernandez 2015-09-29 17:42:25 +0000 Solved here: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=99fc78653a6933e24e57aed9df246b3fda529ca8 54848 2 alejandro.hernandez 2015-09-30 20:44:36 +0000 My mistake, this wasn't fixed completely, working on it 55042 3 alejandro.hernandez 2015-10-07 19:43:41 +0000 This started causing errors with the kernel too, a race condition was created when using patched sources between kernel_configme and unpack_and_patch, producing errors during kernel configuration. Also, as Richard Purdie noted, we don't need to have multiple identical gcc source tarballs. I sent a patch to the ML fixing both these new issues along with the original one. 56944 4 alejandro.hernandez 2015-12-02 15:03:37 +0000 Fixed: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2f0ff3abb448dc23d9420986fcbab80c9da7cd25 57584 5 bogdanx.a.voiculescu 2016-01-06 14:40:42 +0000 Verified on master 2cd061a29a94fdcdfec86732e6bcbb71c12c4afc