8593 2015-10-28 03:47:50 +0000 The head files of ncurses installing into sysroot seems different in multiple times compilation 2017-06-06 12:35:14 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED FIXED Medium normal 2.4 1 emincemnt ross.burton bluelightning meta.mr.watcher meta.watcher poky.bs.watcher poky.watcher randy.macleod --- --- Don't know oldest_to_newest 55870 0 emincemnt 2015-10-28 03:47:50 +0000 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? 55874 1 bluelightning 2015-10-28 08:32:23 +0000 When you say "second build" is that being restored from the sstate cache, or rebuilding from source? 55875 2 emincemnt 2015-10-28 08:54:18 +0000 (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/" 55878 3 bluelightning 2015-10-28 09:15:46 +0000 OK, that being the case, what are you doing between the first and second builds? 55931 4 emincemnt 2015-10-28 14:59:41 +0000 I did not modify any code, just directly create a new dir and recompiled. 55933 5 bluelightning 2015-10-28 15:04:21 +0000 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? 55936 6 emincemnt 2015-10-28 15:28:23 +0000 (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. 55937 7 bluelightning 2015-10-28 15:35:49 +0000 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? 55956 8 emincemnt 2015-10-29 02:49:59 +0000 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}. 55966 9 bluelightning 2015-10-29 09:44:39 +0000 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). 56025 10 emincemnt 2015-10-30 03:54:24 +0000 (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. 56033 11 bluelightning 2015-10-30 07:57:04 +0000 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). 56518 12 ross.burton 2015-11-17 11:36:55 +0000 Yunming Shi: what release of oe-core/yocto/poky were you using for this? 73739 13 emincemnt 2017-06-06 11:30:51 +0000 (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. 73743 14 ross.burton 2017-06-06 11:52:20 +0000 Are you aware that 1.2 is over five years old? Please considering moving to a newer (supported, not prone to security problems) release. 73745 15 emincemnt 2017-06-06 12:35:14 +0000 (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.