Bug 894

Created attachment 115 [details]
conf file I used for sstate test

Created attachment 116 [details]
screen output when building poky-image-minimal with sstate cache

Could you include the config.log please?
(/home/jxu49/osel/poky-rc3-sstate-tmp/build/tmp/work/i586-poky-linux/libtool-cross-2.4-r2/libtool-2.4/config.log)

For reference, configure failures like this are near impossible to debug without that log file.

Created attachment 117 [details]
config.log for libtool-cross-2.4-r2/libtool-2.4

(In reply to comment #3)
> Could you include the config.log please?
> (/home/jxu49/osel/poky-rc3-sstate-tmp/build/tmp/work/i586-poky-linux/libtool-cross-2.4-r2/libtool-2.4/config.log)
> For reference, configure failures like this are near impossible to debug
> without that log file.

Sorry, Richard.
I should include the config.log when I submit the bug.

Thanks Jianjun. Just to quote this to make it easier to reference, the real error is:

configure:3650: checking whether the C compiler works
configure:3672: i586-poky-linux-gcc -march=i586 --sysroot=/home/jxu49/osel/poky-rc3-sstate-tmp/build/tmp/sysroots/qemux86 -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb -feliminate-unused-debug-types  -Wl,-O1  -Wl,--as-needed conftest.c  >&5
collect2: cannot find 'ld'
configure:3676: $? = 1
configure:3714: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Libtool"
| #define PACKAGE_TARNAME "libtool"
| #define PACKAGE_VERSION "2.4"
| #define PACKAGE_STRING "GNU Libtool 2.4"
| #define PACKAGE_BUGREPORT "bug-libtool@gnu.org"
| #define PACKAGE_URL "http://www.gnu.org/software/libtool/"
| #define PACKAGE "libtool"
| #define VERSION "2.4"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3719: error: in `/home/jxu49/osel/poky-rc3-sstate-tmp/build/tmp/work/i586-poky-linux/libtool-cross-2.4-r2/libtool-2.4':
configure:3723: error: C compiler cannot create executables
See `config.log' for more details.

i.e. ld cannot be found (which should be a symlink created by binutils-cross in the libexec directory structure).

the 'ld' is missing because bitbake temps to rebuild all the toolchains after sstate installation:

NOTE: Executing RunQueue Tasks
NOTE: Running task 1060 of 1861 (ID: 843, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-devtools/binutils/binutils-cross_2.21.bb, do_setscene)
NOTE: Running task 1061 of 1861 (ID: 656, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.37.2.bb, do_setscene)
NOTE: Running task 1062 of 1861 (ID: 898, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-devtools/gcc/gcc-cross-intermediate_4.5.1.bb, do_setscene)
NOTE: Running task 1063 of 1861 (ID: 1580, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-devtools/gcc/gcc-cross-initial_4.5.1.bb, do_setscene)
NOTE: Running task 1064 of 1861 (ID: 1327, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-core/eglibc/eglibc-initial_2.12.bb, do_setscene)
NOTE: Running task 1065 of 1861 (ID: 471, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-core/eglibc/eglibc_2.12.bb, do_setscene)
NOTE: Running task 1066 of 1861 (ID: 449, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-devtools/gcc/gcc-cross_4.5.1.bb, do_setscene)
NOTE: Running task 1067 of 1861 (ID: 887, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-devtools/gcc/libgcc_4.5.1.bb, do_setscene)
NOTE: Running task 1068 of 1861 (ID: 460, /home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-devtools/gcc/gcc-runtime_4.5.1.bb, do_setscene)

then later libtool-cross.do_configure is executed before toolchain rebuild is ready (binutils-cross is still in do_compile), and that's why 'ld' can't be found. 

There may be two issues related:

a) why are those packages rebuilt even with the same source tree?

After a careful check, there's only do_populate_sysroot_setscene executed but no do_package_write_rpm_setscene. That means all the do_package_write_rpm needs rebuilt as required by the rootfs. This is echoed by Jiajun's another observation that bitbake a single package succeeds because only sysroot is required in that case. 

b) why is dependency chain not followed in the rebuild when sstate tasks are partially installed?

this may be another issue hidden by this bug. normally sstate reuse is in package granule, either full reusing all the setscene tasks or not reuse any of them. When only one setscene task is reused like do_populate_sysroot here, then this issue jumps out

I tried to compare the sigdata for a):

jxu49@vt-nhm4:~/osel/poky-rc3-sstate/build$ bitbake-diffsigs tmp/stamps/i686-linux/binutils-native-2.21-r0.do_package_write_rpm.sigdata.0d85456fa5c83fe001525b35230ee2d6 ../../poky-rc3-sstate-tmp/build/tmp/stamps/i686-linux/binutils-native-2.21-r0.do_package_write_rpm.sigdata.9ee135baa8d1b632b266c83634f426bb 
Dependency on task virtual:native:/home/jxu49/osel/poky-rc3-sstate/meta/recipes-devtools/binutils/binutils_2.21.bb.do_package was added
Dependency on task virtual:native:/home/jxu49/osel/poky-rc3-sstate-tmp/meta/recipes-devtools/binutils/binutils_2.21.bb.do_package was removed

However it doesn't give useful information. Above difference is simply a sigdata difference, which is not counted into the signature calculation (actually I sent one patch for this before but it looks that it's not accepted). Here the checksum is different but no variable/hash difference is reported.

weird... but I guess it may be related to recent rootfs_rpm related changes...


There could be a potential bug why dependency chain is not followed when sstate

(In reply to comment #7)
> There could be a potential bug why dependency chain is not followed when sstate

above sentence is a trash, forgot to remove it

OK, this is caused by do_populate_lic, which depends on COMMON_LICENSE_DIR which further depends POKYBASE. POKYBASE points to source directory, and thus causes trouble.

do_package depends on do_populate_lic, and thus is also impacted.

I'm adding POKYBASE to bb whitelist, and Jiajun is verifying it now.

this may be the reason for bug 903 too...

patch sent out

See comments in #790 too, looks like related issues, some are now fixed but not all.

Its #792, not #790

I saw Kevin's patch is already in bernard branch with gold build. So having a try with gold build, the issue is fixed now. So verify the bug as fixed.

branch: bernard/poky master tree
meta-intel commit: 83384c3e83d69245dfe19e36b2a64c8973ad8462
poky commit: 82af8b9fb6d6d1439943fd15b8a75c0e663e4a45

Verify it as fixed in gold build.