Khem Raj wrote: > you could try couple of things. Firstly try to isolate if its a > bitbake problem or not > likely its not but still make sure. You can go into the workdir and > run the task script > run.do_<task> whatever it is stuck at. If it succeeeds then you know > its a problem with > bitbake if not then the build mechanism for this particular package > has problem. You might > try to disable parallel build i.e. use -j 1 to make sure that its not > some parallel build > issue.
I made some tests on this. First result was that if calling > bitbake drapptempl -c clean > bitbake drapptempl Ctrl-C > bitbake drapptempl the first build request freezes in do_compile stage, the second one succeeds (seen in 5 of 5 test runs). Also calling run.do_compile succeeds everytime if tried after the first freeze. After that i checked the parallel build options in my local.conf. The tests above were made with PARALLEL_MAKE = "-j 4" BB_NUMBER_THREADS = "4" I tried to set the BB_NUMBER_THREADS to 1 but the problem was still existing. After that i tried to set the PARALLEL_MAKE to "-j 1" and no the recipe was build fine. :) So it seems that there is a problem with parallel make. But it only occurs in a few of our recipes. Therefor i believe that there must be something special in there makefiles/recipes. After a detailed inspection i noted that they all depend on a library which uses glib (incl. some tools like gob2). The library itself does not have the build problems. But could the problem result from this? Steffen _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
