The head files of ncurses installing into sysroot seems different in multiple times compilation: 1st build: project/tmp/sysroots/armA9le/usr/include/ncurses: cursesapp.h cursesm.h cursslk.h form.h ncurses_dll.h termcap.h tic.h cursesf.h cursesp.h eti.h menu.h ncurses.h term_entry.h unctrl.h curses.h cursesw.h etip.h nc_tparm.h panel.h term.h projecttmp/sysroots/armA9le/usr/include/ncursesw: cursesapp.h cursesm.h cursslk.h form.h ncurses_dll.h termcap.h tic.h cursesf.h cursesp.h eti.h menu.h ncurses.h term_entry.h unctrl.h curses.h cursesw.h etip.h nc_tparm.h panel.h term.h 2nd build: project/tmp/sysroots/armA9le/usr/include/ncurses: ---->empty dir projecttmp/sysroots/armA9le/usr/include/ncursesw: cursesapp.h cursesm.h cursslk.h form.h ncurses_dll.h termcap.h tic.h cursesf.h cursesp.h eti.h menu.h ncurses.h term_entry.h unctrl.h curses.h cursesw.h etip.h nc_tparm.h panel.h term.h This could be a issue ? Does anyone know how to fix it or how to explain this?
When you say "second build" is that being restored from the sstate cache, or rebuilding from source?
(In reply to comment #1) > When you say "second build" is that being restored from the sstate cache, or > rebuilding from source? I mean rebuilding from source. And I found a difference between "log.do_populate_sysroot" of each building.The log in the 1st build have one more line: "DEBUG: Staging files from /ci/build/workspace_armA9le/tmp/work/armv7a-linux-gnueabi/ncurses-5.7-r10.1/sysroot-destdir/ to /ci/build/workspace_armA9le/tmp/sysroots/armA9le/"
OK, that being the case, what are you doing between the first and second builds?
I did not modify any code, just directly create a new dir and recompiled.
I'm still not following I'm afraid - "new dir" - which directory do you mean? the build directory? If so how is that connected to the old directory? By "recompiled" do you mean running bitbake on the same target?
(In reply to comment #5) > I'm still not following I'm afraid - "new dir" - which directory do you > mean? the build directory? If so how is that connected to the old directory? > By "recompiled" do you mean running bitbake on the same target? Sorry to make you confused. Here is what I did, I created a project directory and built once, then I created a new one and built again. But the *.h installed into sysroots acting different in the two projects.
Ok, so these two build directories are completely independent and both built completely from source? Could you compare some of the other logs such as log.do_configure? Also is there a difference in whats in image/ under the workdir for the recipe for each build?
1.Yes, so these two build directories are completely independent and both built completely from source. 2.I compared the logs (log.do_configure log.do_compile and log.do_install), they are totally the same except the time-stamp. 3.There's few adjustments for ncurses_5.7.bb: ==================================================================== do_chmod(){ install -d ${D}/usr/include/ncursesw install -d ${D}/usr/include/ncurses install -m 0644 ${D}/usr/include/*.h ${D}/usr/include/ncursesw install -m 0644 ${D}/usr/include/*.h ${D}/usr/include/ncurses cp -r ${D}/usr/include/ncursesw/ ${STAGING_DIR_HOST}${includedir} } addtask do_chmod after do_install before do_package ==================================================================== The task do_chmod makes sure all the *.h will be installed into ${D}.
A couple of problems with the fix you propose: 1) We need to actually fix do_install rather than band-aiding another task function onto it; it is already supposed to be handling these headers 2) You must not copy files directly into the sysroot (the ${STAGING_DIR_HOST} part of it in this case). Files should be installed into ${D} and then the normal staging logic will manage how those get into the sysroot (most importantly, so we know how to remove them later when the recipe is upgraded/cleaned).
(In reply to comment #9) > A couple of problems with the fix you propose: > > 1) We need to actually fix do_install rather than band-aiding another task > function onto it; it is already supposed to be handling these headers > > 2) You must not copy files directly into the sysroot (the > ${STAGING_DIR_HOST} part of it in this case). Files should be installed into > ${D} and then the normal staging logic will manage how those get into the > sysroot (most importantly, so we know how to remove them later when the > recipe is upgraded/cleaned). Thanks for your advice, I add a additional task because the headers I need in ncurses/ and ncursesw/ won't be installed into sysroot as default.
That's not the way to solve it. If you look at sysroot_stage_dirs() in meta/classes/staging.bbclass (which is part of what happens during do_populate_sysroot) you can see that the entire of ${includedir} (/usr/include) is being staged. If there's a problem here either what's already in do_install to install these headers isn't working (possible) or the staging logic isn't working (less likely, because then you'd be seeing much more serious problems).
Yunming Shi: what release of oe-core/yocto/poky were you using for this?
(In reply to comment #12) > Yunming Shi: what release of oe-core/yocto/poky were you using for this? I'm using Yocto 1.2.1, very sorry for took so long to reply.
Are you aware that 1.2 is over five years old? Please considering moving to a newer (supported, not prone to security problems) release.
(In reply to comment #14) > Are you aware that 1.2 is over five years old? Please considering moving to > a newer (supported, not prone to security problems) release. All right, I will. Thank you for your support.