* [Buildroot] Parallel make messes up post-build in -next @ 2014-02-20 9:55 Eric Le Bihan 2014-02-20 13:24 ` Thomas De Schampheleire 2014-02-20 13:42 ` Fabio Porcedda 0 siblings, 2 replies; 14+ messages in thread From: Eric Le Bihan @ 2014-02-20 9:55 UTC (permalink / raw) To: buildroot Hi! I am currently testing the -next branch and I've encountered the following problem: the copy of my overlay and the execution of my post-build script is now performed *after* the generation of my image. Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support for top-level parallel make, fixes the issue. Has anyone else experienced this problem? Best regards, ELB ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 9:55 [Buildroot] Parallel make messes up post-build in -next Eric Le Bihan @ 2014-02-20 13:24 ` Thomas De Schampheleire 2014-02-20 14:13 ` Fabio Porcedda 2014-02-20 13:42 ` Fabio Porcedda 1 sibling, 1 reply; 14+ messages in thread From: Thomas De Schampheleire @ 2014-02-20 13:24 UTC (permalink / raw) To: buildroot On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > Hi! > > I am currently testing the -next branch and I've encountered the following > problem: the copy of my overlay and the execution of my post-build script is > now performed *after* the generation of my image. > > Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support > for top-level parallel make, fixes the issue. > > Has anyone else experienced this problem? I haven't tried it myself yet. But, the rootfs and post build scripts are done from target-finalize, and the rules to make the rootfs depend on target-finalize. This should be fine (but probably is not and we're overlooking something). However, aside from the above I have another doubt: I don't see any special handling for the other special targets like target-purgelocales, target-generatelocales, ... These targets should be run after all generic targets, and before creating the rootfs. As far as I can see, they could now run in parallel with the normal targets, right? Thanks, Thomas ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 13:24 ` Thomas De Schampheleire @ 2014-02-20 14:13 ` Fabio Porcedda 2014-02-20 14:16 ` Arnout Vandecappelle 2014-02-20 14:28 ` Thomas De Schampheleire 0 siblings, 2 replies; 14+ messages in thread From: Fabio Porcedda @ 2014-02-20 14:13 UTC (permalink / raw) To: buildroot On Thu, Feb 20, 2014 at 2:24 PM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan > <eric.le.bihan.dev@free.fr> wrote: >> Hi! >> >> I am currently testing the -next branch and I've encountered the following >> problem: the copy of my overlay and the execution of my post-build script is >> now performed *after* the generation of my image. >> >> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support >> for top-level parallel make, fixes the issue. >> >> Has anyone else experienced this problem? > > I haven't tried it myself yet. > But, the rootfs and post build scripts are done from target-finalize, > and the rules to make the rootfs depend on target-finalize. > This should be fine (but probably is not and we're overlooking something). > > However, aside from the above I have another doubt: I don't see any > special handling for the other special targets like > target-purgelocales, target-generatelocales, ... These targets should > be run after all generic targets, and before creating the rootfs. As > far as I can see, they could now run in parallel with the normal > targets, right? Yes, it's a thing to fix for proper parallel bulding support, it's on my todo list. The targets target-finalize, target-purgelocales, target-generatelocales, toolchain-eclipse-register can be executed in parallel after building the generic targets? Regards -- Fabio Porcedda ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 14:13 ` Fabio Porcedda @ 2014-02-20 14:16 ` Arnout Vandecappelle 2014-02-20 14:28 ` Thomas De Schampheleire 1 sibling, 0 replies; 14+ messages in thread From: Arnout Vandecappelle @ 2014-02-20 14:16 UTC (permalink / raw) To: buildroot On 20/02/14 15:13, Fabio Porcedda wrote: > On Thu, Feb 20, 2014 at 2:24 PM, Thomas De Schampheleire > <patrickdepinguin@gmail.com> wrote: >> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan >> <eric.le.bihan.dev@free.fr> wrote: >>> Hi! >>> >>> I am currently testing the -next branch and I've encountered the following >>> problem: the copy of my overlay and the execution of my post-build script is >>> now performed *after* the generation of my image. >>> >>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support >>> for top-level parallel make, fixes the issue. >>> >>> Has anyone else experienced this problem? >> >> I haven't tried it myself yet. >> But, the rootfs and post build scripts are done from target-finalize, >> and the rules to make the rootfs depend on target-finalize. >> This should be fine (but probably is not and we're overlooking something). >> >> However, aside from the above I have another doubt: I don't see any >> special handling for the other special targets like >> target-purgelocales, target-generatelocales, ... These targets should >> be run after all generic targets, and before creating the rootfs. As >> far as I can see, they could now run in parallel with the normal >> targets, right? > > Yes, it's a thing to fix for proper parallel bulding support, it's on > my todo list. > > The targets target-finalize, target-purgelocales, > target-generatelocales, toolchain-eclipse-register can be executed in > parallel after building the generic targets? I think target-finalize should depend on all other target-*. It's something that you may want to call from the command line in order to get an up-to-date target directory. toolchain-eclipse-register can be done in parallel with all the rest, it should just depend on toolchain. There is nothing really that depends on it, so probably 'world' is the best choice. Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 14:13 ` Fabio Porcedda 2014-02-20 14:16 ` Arnout Vandecappelle @ 2014-02-20 14:28 ` Thomas De Schampheleire 2014-02-20 14:48 ` Arnout Vandecappelle 1 sibling, 1 reply; 14+ messages in thread From: Thomas De Schampheleire @ 2014-02-20 14:28 UTC (permalink / raw) To: buildroot Hi Fabio, On Thu, Feb 20, 2014 at 3:13 PM, Fabio Porcedda <fabio.porcedda@gmail.com> wrote: [..] > > Yes, it's a thing to fix for proper parallel bulding support, it's on > my todo list. > > The targets target-finalize, target-purgelocales, > target-generatelocales, toolchain-eclipse-register can be executed in > parallel after building the generic targets? Since you can select both purgelocales and generatelocales, I would expect they need to be sequential: first purge then generate (as done today). I'd also expect that target-finalize should be finished before starting the locale stuff, as the post-build script or overlay may add additional locale stuff that needs to be purged. Best regards, Thomas ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 14:28 ` Thomas De Schampheleire @ 2014-02-20 14:48 ` Arnout Vandecappelle 2014-02-20 15:04 ` Thomas De Schampheleire 0 siblings, 1 reply; 14+ messages in thread From: Arnout Vandecappelle @ 2014-02-20 14:48 UTC (permalink / raw) To: buildroot On 20/02/14 15:28, Thomas De Schampheleire wrote: > Hi Fabio, > > On Thu, Feb 20, 2014 at 3:13 PM, Fabio Porcedda > <fabio.porcedda@gmail.com> wrote: > [..] >> >> Yes, it's a thing to fix for proper parallel bulding support, it's on >> my todo list. >> >> The targets target-finalize, target-purgelocales, >> target-generatelocales, toolchain-eclipse-register can be executed in >> parallel after building the generic targets? > > Since you can select both purgelocales and generatelocales, I would > expect they need to be sequential: first purge then generate (as done > today). True. > I'd also expect that target-finalize should be finished before > starting the locale stuff, as the post-build script or overlay may add > additional locale stuff that needs to be purged. Hm, I would actually expect the reverse: whatever my post-build script or overlay does should be final, and not be removed again by purgelocales. But that is in fact not what happens at the moment. Regards, Arnout > > Best regards, > Thomas > -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 14:48 ` Arnout Vandecappelle @ 2014-02-20 15:04 ` Thomas De Schampheleire 0 siblings, 0 replies; 14+ messages in thread From: Thomas De Schampheleire @ 2014-02-20 15:04 UTC (permalink / raw) To: buildroot On Thu, Feb 20, 2014 at 3:48 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > On 20/02/14 15:28, Thomas De Schampheleire wrote: >> Hi Fabio, >> >> On Thu, Feb 20, 2014 at 3:13 PM, Fabio Porcedda >> <fabio.porcedda@gmail.com> wrote: >> [..] >>> >>> Yes, it's a thing to fix for proper parallel bulding support, it's on >>> my todo list. >>> >>> The targets target-finalize, target-purgelocales, >>> target-generatelocales, toolchain-eclipse-register can be executed in >>> parallel after building the generic targets? >> >> Since you can select both purgelocales and generatelocales, I would >> expect they need to be sequential: first purge then generate (as done >> today). > > True. > >> I'd also expect that target-finalize should be finished before >> starting the locale stuff, as the post-build script or overlay may add >> additional locale stuff that needs to be purged. > > Hm, I would actually expect the reverse: whatever my post-build script > or overlay does should be final, and not be removed again by > purgelocales. But that is in fact not what happens at the moment. I also had the same doubt, but what I wrote is just to mimic the non-parallel behavior. The changing of the order of locale stuff and post-build is not related to the parallel build. Best regards, Thomas ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 9:55 [Buildroot] Parallel make messes up post-build in -next Eric Le Bihan 2014-02-20 13:24 ` Thomas De Schampheleire @ 2014-02-20 13:42 ` Fabio Porcedda 2014-02-20 14:00 ` Eric Le Bihan 2014-02-20 14:00 ` Thomas De Schampheleire 1 sibling, 2 replies; 14+ messages in thread From: Fabio Porcedda @ 2014-02-20 13:42 UTC (permalink / raw) To: buildroot On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > Hi! > > I am currently testing the -next branch and I've encountered the following > problem: the copy of my overlay and the execution of my post-build script is > now performed *after* the generation of my image. > > Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support > for top-level parallel make, fixes the issue. > > Has anyone else experienced this problem? > Can you try this patch? diff --git a/Makefile b/Makefile index 20aabd6..de568e3 100644 --- a/Makefile +++ b/Makefile @@ -507,6 +507,8 @@ endif STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \) STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so* $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print +$(TARGETS_ROOTFS): target-finalize + target-finalize: $(TARGETS) rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \ $(TARGET_DIR)/usr/lib/pkgconfig $(TARGET_DIR)/usr/share/pkgconfig \ @@ -534,8 +536,6 @@ endif find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \ xargs -r $(KSTRIPCMD); fi -$(TARGETS_ROOTFS): target-finalize - # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads # besides the one in which crash occurred; or SIGTRAP kills my program when # I set a breakpoint" Regards -- Fabio Porcedda ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 13:42 ` Fabio Porcedda @ 2014-02-20 14:00 ` Eric Le Bihan 2014-02-20 14:11 ` Fabio Porcedda 2014-02-20 14:00 ` Thomas De Schampheleire 1 sibling, 1 reply; 14+ messages in thread From: Eric Le Bihan @ 2014-02-20 14:00 UTC (permalink / raw) To: buildroot Hi! On Thu, Feb 20, 2014 at 02:42:17PM +0100, Fabio Porcedda wrote: > On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan > <eric.le.bihan.dev@free.fr> wrote: > > Hi! > > > > I am currently testing the -next branch and I've encountered the following > > problem: the copy of my overlay and the execution of my post-build script is > > now performed *after* the generation of my image. > > > > Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support > > for top-level parallel make, fixes the issue. > > > > Has anyone else experienced this problem? > > > > Can you try this patch? > > diff --git a/Makefile b/Makefile > index 20aabd6..de568e3 100644 > --- a/Makefile > +++ b/Makefile > @@ -507,6 +507,8 @@ endif > STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \) > STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so* > $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print > > +$(TARGETS_ROOTFS): target-finalize > + > target-finalize: $(TARGETS) > rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \ > $(TARGET_DIR)/usr/lib/pkgconfig > $(TARGET_DIR)/usr/share/pkgconfig \ > @@ -534,8 +536,6 @@ endif > find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \ > xargs -r $(KSTRIPCMD); fi > > -$(TARGETS_ROOTFS): target-finalize > - > # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads > # besides the one in which crash occurred; or SIGTRAP kills my program when > # I set a breakpoint" The patch fixes the issue. Thank you very much! Best regards, ELB ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 14:00 ` Eric Le Bihan @ 2014-02-20 14:11 ` Fabio Porcedda 0 siblings, 0 replies; 14+ messages in thread From: Fabio Porcedda @ 2014-02-20 14:11 UTC (permalink / raw) To: buildroot On Thu, Feb 20, 2014 at 3:00 PM, Eric Le Bihan <eric.le.bihan.dev@free.fr> wrote: > Hi! > > On Thu, Feb 20, 2014 at 02:42:17PM +0100, Fabio Porcedda wrote: >> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan >> <eric.le.bihan.dev@free.fr> wrote: >> > Hi! >> > >> > I am currently testing the -next branch and I've encountered the following >> > problem: the copy of my overlay and the execution of my post-build script is >> > now performed *after* the generation of my image. >> > >> > Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support >> > for top-level parallel make, fixes the issue. >> > >> > Has anyone else experienced this problem? >> > >> >> Can you try this patch? >> >> diff --git a/Makefile b/Makefile >> index 20aabd6..de568e3 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -507,6 +507,8 @@ endif >> STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \) >> STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so* >> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print >> >> +$(TARGETS_ROOTFS): target-finalize >> + >> target-finalize: $(TARGETS) >> rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \ >> $(TARGET_DIR)/usr/lib/pkgconfig >> $(TARGET_DIR)/usr/share/pkgconfig \ >> @@ -534,8 +536,6 @@ endif >> find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \ >> xargs -r $(KSTRIPCMD); fi >> >> -$(TARGETS_ROOTFS): target-finalize >> - >> # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads >> # besides the one in which crash occurred; or SIGTRAP kills my program when >> # I set a breakpoint" > The patch fixes the issue. Thank you very much! That's great, i will send shortly a patch to fix this issue. Thanks for reporting and testing. Sorry for the trouble. Regards -- Fabio Porcedda ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 13:42 ` Fabio Porcedda 2014-02-20 14:00 ` Eric Le Bihan @ 2014-02-20 14:00 ` Thomas De Schampheleire 2014-02-20 14:03 ` Thomas De Schampheleire 2014-02-20 14:07 ` Fabio Porcedda 1 sibling, 2 replies; 14+ messages in thread From: Thomas De Schampheleire @ 2014-02-20 14:00 UTC (permalink / raw) To: buildroot Hi Fabio, On Thu, Feb 20, 2014 at 2:42 PM, Fabio Porcedda <fabio.porcedda@gmail.com> wrote: > On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan > <eric.le.bihan.dev@free.fr> wrote: >> Hi! >> >> I am currently testing the -next branch and I've encountered the following >> problem: the copy of my overlay and the execution of my post-build script is >> now performed *after* the generation of my image. >> >> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support >> for top-level parallel make, fixes the issue. >> >> Has anyone else experienced this problem? >> > > Can you try this patch? > > diff --git a/Makefile b/Makefile > index 20aabd6..de568e3 100644 > --- a/Makefile > +++ b/Makefile > @@ -507,6 +507,8 @@ endif > STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \) > STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so* > $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print > > +$(TARGETS_ROOTFS): target-finalize > + > target-finalize: $(TARGETS) > rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \ > $(TARGET_DIR)/usr/lib/pkgconfig > $(TARGET_DIR)/usr/share/pkgconfig \ > @@ -534,8 +536,6 @@ endif > find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \ > xargs -r $(KSTRIPCMD); fi > > -$(TARGETS_ROOTFS): target-finalize > - > # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads > # besides the one in which crash occurred; or SIGTRAP kills my program when > # I set a breakpoint" > Why do you think this would change anything? As far as I know, the order of the dependency expression does not matter... ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 14:00 ` Thomas De Schampheleire @ 2014-02-20 14:03 ` Thomas De Schampheleire 2014-02-20 14:15 ` Fabio Porcedda 2014-02-20 14:07 ` Fabio Porcedda 1 sibling, 1 reply; 14+ messages in thread From: Thomas De Schampheleire @ 2014-02-20 14:03 UTC (permalink / raw) To: buildroot Hi, On Thu, Feb 20, 2014 at 3:00 PM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > Hi Fabio, > > On Thu, Feb 20, 2014 at 2:42 PM, Fabio Porcedda > <fabio.porcedda@gmail.com> wrote: >> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan >> <eric.le.bihan.dev@free.fr> wrote: >>> Hi! >>> >>> I am currently testing the -next branch and I've encountered the following >>> problem: the copy of my overlay and the execution of my post-build script is >>> now performed *after* the generation of my image. >>> >>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support >>> for top-level parallel make, fixes the issue. >>> >>> Has anyone else experienced this problem? >>> >> >> Can you try this patch? >> >> diff --git a/Makefile b/Makefile >> index 20aabd6..de568e3 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -507,6 +507,8 @@ endif >> STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \) >> STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so* >> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print >> >> +$(TARGETS_ROOTFS): target-finalize >> + >> target-finalize: $(TARGETS) >> rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \ >> $(TARGET_DIR)/usr/lib/pkgconfig >> $(TARGET_DIR)/usr/share/pkgconfig \ >> @@ -534,8 +536,6 @@ endif >> find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \ >> xargs -r $(KSTRIPCMD); fi >> >> -$(TARGETS_ROOTFS): target-finalize >> - >> # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads >> # besides the one in which crash occurred; or SIGTRAP kills my program when >> # I set a breakpoint" >> > > > Why do you think this would change anything? > As far as I know, the order of the dependency expression does not matter... I spoke too soon. There was indeed an actual bug in the original patch, adding a new rule in between the target-finalize rule. It was not so obvious because of the many empty lines in target-finalize, though. Fabio, will you send a patch for this? Thanks, Thomas ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 14:03 ` Thomas De Schampheleire @ 2014-02-20 14:15 ` Fabio Porcedda 0 siblings, 0 replies; 14+ messages in thread From: Fabio Porcedda @ 2014-02-20 14:15 UTC (permalink / raw) To: buildroot On Thu, Feb 20, 2014 at 3:03 PM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > Hi, > > On Thu, Feb 20, 2014 at 3:00 PM, Thomas De Schampheleire > <patrickdepinguin@gmail.com> wrote: >> Hi Fabio, >> >> On Thu, Feb 20, 2014 at 2:42 PM, Fabio Porcedda >> <fabio.porcedda@gmail.com> wrote: >>> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan >>> <eric.le.bihan.dev@free.fr> wrote: >>>> Hi! >>>> >>>> I am currently testing the -next branch and I've encountered the following >>>> problem: the copy of my overlay and the execution of my post-build script is >>>> now performed *after* the generation of my image. >>>> >>>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support >>>> for top-level parallel make, fixes the issue. >>>> >>>> Has anyone else experienced this problem? >>>> >>> >>> Can you try this patch? >>> >>> diff --git a/Makefile b/Makefile >>> index 20aabd6..de568e3 100644 >>> --- a/Makefile >>> +++ b/Makefile >>> @@ -507,6 +507,8 @@ endif >>> STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \) >>> STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so* >>> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print >>> >>> +$(TARGETS_ROOTFS): target-finalize >>> + >>> target-finalize: $(TARGETS) >>> rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \ >>> $(TARGET_DIR)/usr/lib/pkgconfig >>> $(TARGET_DIR)/usr/share/pkgconfig \ >>> @@ -534,8 +536,6 @@ endif >>> find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \ >>> xargs -r $(KSTRIPCMD); fi >>> >>> -$(TARGETS_ROOTFS): target-finalize >>> - >>> # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads >>> # besides the one in which crash occurred; or SIGTRAP kills my program when >>> # I set a breakpoint" >>> >> >> >> Why do you think this would change anything? >> As far as I know, the order of the dependency expression does not matter... > > I spoke too soon. > There was indeed an actual bug in the original patch, adding a new > rule in between the target-finalize rule. It was not so obvious > because of the many empty lines in target-finalize, though. > > Fabio, will you send a patch for this? That's for sure! Regards -- Fabio Porcedda ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] Parallel make messes up post-build in -next 2014-02-20 14:00 ` Thomas De Schampheleire 2014-02-20 14:03 ` Thomas De Schampheleire @ 2014-02-20 14:07 ` Fabio Porcedda 1 sibling, 0 replies; 14+ messages in thread From: Fabio Porcedda @ 2014-02-20 14:07 UTC (permalink / raw) To: buildroot On Thu, Feb 20, 2014 at 3:00 PM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > Hi Fabio, > > On Thu, Feb 20, 2014 at 2:42 PM, Fabio Porcedda > <fabio.porcedda@gmail.com> wrote: >> On Thu, Feb 20, 2014 at 10:55 AM, Eric Le Bihan >> <eric.le.bihan.dev@free.fr> wrote: >>> Hi! >>> >>> I am currently testing the -next branch and I've encountered the following >>> problem: the copy of my overlay and the execution of my post-build script is >>> now performed *after* the generation of my image. >>> >>> Reverting commit a24877586a566e052897e50e6a0c2f53cfb029f5, which adds support >>> for top-level parallel make, fixes the issue. >>> >>> Has anyone else experienced this problem? >>> >> >> Can you try this patch? >> >> diff --git a/Makefile b/Makefile >> index 20aabd6..de568e3 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -507,6 +507,8 @@ endif >> STRIP_FIND_CMD += -type f \( -perm /111 -o -name '*.so*' \) >> STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so* >> $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print >> >> +$(TARGETS_ROOTFS): target-finalize >> + >> target-finalize: $(TARGETS) >> rm -rf $(TARGET_DIR)/usr/include $(TARGET_DIR)/usr/share/aclocal \ >> $(TARGET_DIR)/usr/lib/pkgconfig >> $(TARGET_DIR)/usr/share/pkgconfig \ >> @@ -534,8 +536,6 @@ endif >> find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \ >> xargs -r $(KSTRIPCMD); fi >> >> -$(TARGETS_ROOTFS): target-finalize >> - >> # See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads >> # besides the one in which crash occurred; or SIGTRAP kills my program when >> # I set a breakpoint" >> > > > Why do you think this would change anything? > As far as I know, the order of the dependency expression does not matter... It's my fault for putting the new rule inside another target so i splitted the previous target... I was confused by the empty line inside the previous rule, it was my fault. It is a bug introduced in my latest revision of the patch set :( Regards -- Fabio Porcedda ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-02-20 15:04 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-20 9:55 [Buildroot] Parallel make messes up post-build in -next Eric Le Bihan 2014-02-20 13:24 ` Thomas De Schampheleire 2014-02-20 14:13 ` Fabio Porcedda 2014-02-20 14:16 ` Arnout Vandecappelle 2014-02-20 14:28 ` Thomas De Schampheleire 2014-02-20 14:48 ` Arnout Vandecappelle 2014-02-20 15:04 ` Thomas De Schampheleire 2014-02-20 13:42 ` Fabio Porcedda 2014-02-20 14:00 ` Eric Le Bihan 2014-02-20 14:11 ` Fabio Porcedda 2014-02-20 14:00 ` Thomas De Schampheleire 2014-02-20 14:03 ` Thomas De Schampheleire 2014-02-20 14:15 ` Fabio Porcedda 2014-02-20 14:07 ` Fabio Porcedda
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.