* elfutils - missing dependency on bzip2? @ 2012-02-26 17:25 Steve Sakoman 2012-02-26 23:24 ` Richard Purdie 0 siblings, 1 reply; 6+ messages in thread From: Steve Sakoman @ 2012-02-26 17:25 UTC (permalink / raw) To: Patches and discussions about the oe-core layer After a pull this morning the rebuild if elfutils fails with: | /usr/bin/ld: cannot find -lbz2 | collect2: ld returned 1 exit status | make[3]: *** [libdw.so] Error 1 | make[3]: Leaving directory `/media/Work/yocto/tmp/work/i686-linux/elfutils-native-0.148-r5/elfutils-0.148/libdw' If I build bzip2-native and then rebuild elfutils-native all is well and the build continues until the next failure (mesa-dri-glsl-native, fwiw, haven't investigated that one yet). Anyone else see this, or is it just another case of my build machines being in a strange state? Steve ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: elfutils - missing dependency on bzip2? 2012-02-26 17:25 elfutils - missing dependency on bzip2? Steve Sakoman @ 2012-02-26 23:24 ` Richard Purdie 2012-02-27 0:34 ` Steve Sakoman 0 siblings, 1 reply; 6+ messages in thread From: Richard Purdie @ 2012-02-26 23:24 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Sun, 2012-02-26 at 09:25 -0800, Steve Sakoman wrote: > After a pull this morning the rebuild if elfutils fails with: > > | /usr/bin/ld: cannot find -lbz2 > | collect2: ld returned 1 exit status > | make[3]: *** [libdw.so] Error 1 > | make[3]: Leaving directory > `/media/Work/yocto/tmp/work/i686-linux/elfutils-native-0.148-r5/elfutils-0.148/libdw' > > If I build bzip2-native and then rebuild elfutils-native all is well > and the build continues until the next failure (mesa-dri-glsl-native, > fwiw, haven't investigated that one yet). This sounds like there might be a floating dependency in elfutils on bzip2, if its present. We probably need to lock that down one way or another. > Anyone else see this, or is it just another case of my build machines > being in a strange state? I've seen mesa-dri-glsl-native myself and if its the same issue, this is something the signature changes have highlighted. It was there before, that change just exposed it. Basically, the problem is compile running twice. You could do it before with something like: bitbake mesa-dri-glsl-native bitbake mesa-dri-glsl-native -c compile -f We either need to fix these makefile issues or run "make clean" against them before rerunning make. Cheers, Richard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: elfutils - missing dependency on bzip2? 2012-02-26 23:24 ` Richard Purdie @ 2012-02-27 0:34 ` Steve Sakoman 2012-02-27 6:30 ` Steve Sakoman 0 siblings, 1 reply; 6+ messages in thread From: Steve Sakoman @ 2012-02-27 0:34 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Richard Purdie On Sun, Feb 26, 2012 at 3:24 PM, Richard Purdie <rpurdie@rpsys.net> wrote: > On Sun, 2012-02-26 at 09:25 -0800, Steve Sakoman wrote: >> After a pull this morning the rebuild if elfutils fails with: >> >> | /usr/bin/ld: cannot find -lbz2 >> | collect2: ld returned 1 exit status >> | make[3]: *** [libdw.so] Error 1 >> | make[3]: Leaving directory >> `/media/Work/yocto/tmp/work/i686-linux/elfutils-native-0.148-r5/elfutils-0.148/libdw' >> >> If I build bzip2-native and then rebuild elfutils-native all is well >> and the build continues until the next failure (mesa-dri-glsl-native, >> fwiw, haven't investigated that one yet). > > This sounds like there might be a floating dependency in elfutils on > bzip2, if its present. We probably need to lock that down one way or > another. > >> Anyone else see this, or is it just another case of my build machines >> being in a strange state? > > I've seen mesa-dri-glsl-native myself and if its the same issue, this is > something the signature changes have highlighted. It was there before, > that change just exposed it. > > Basically, the problem is compile running twice. You could do it before > with something like: > > bitbake mesa-dri-glsl-native > bitbake mesa-dri-glsl-native -c compile -f > > We either need to fix these makefile issues or run "make clean" against > them before rerunning make. FWIW, I also had build failures on docbook-utils-native and libzypp. In all cases a -c cleansstate and rebuild got me back to being productive. I'm on a bit of a deadline so I didn't have time to research a proper fix for each. The docbook-utils errors (and there were many) started with: | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" for which no system identifier could be generated | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" for which no system identifier could be generated | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" for which no system identifier could be generated | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here And the libzypp error: | /media/Work/yocto/tmp/sysroots/i686-linux/usr/bin/cmake -E cmake_progress_report /media/Work/yocto/tmp/work/omap3_multi-poky-linux-gnueabi/libzypp-0.0-git1+15b6c52260bbc52b3d8e585e271b67e10cc7c433-r18/git/CMakeFiles | make[2]: *** No rule to make target `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libcrypto.so', needed by `zypp/libzypp.so.810.1.0'. Stop. Sorry I don't have time to dig into the issues at the moment . . . Steve > > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: elfutils - missing dependency on bzip2? 2012-02-27 0:34 ` Steve Sakoman @ 2012-02-27 6:30 ` Steve Sakoman 2012-02-27 6:38 ` Martin Jansa 0 siblings, 1 reply; 6+ messages in thread From: Steve Sakoman @ 2012-02-27 6:30 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Richard Purdie On Sun, Feb 26, 2012 at 4:34 PM, Steve Sakoman <sakoman@gmail.com> wrote: > On Sun, Feb 26, 2012 at 3:24 PM, Richard Purdie <rpurdie@rpsys.net> wrote: >> On Sun, 2012-02-26 at 09:25 -0800, Steve Sakoman wrote: >>> After a pull this morning the rebuild if elfutils fails with: >>> >>> | /usr/bin/ld: cannot find -lbz2 >>> | collect2: ld returned 1 exit status >>> | make[3]: *** [libdw.so] Error 1 >>> | make[3]: Leaving directory >>> `/media/Work/yocto/tmp/work/i686-linux/elfutils-native-0.148-r5/elfutils-0.148/libdw' >>> >>> If I build bzip2-native and then rebuild elfutils-native all is well >>> and the build continues until the next failure (mesa-dri-glsl-native, >>> fwiw, haven't investigated that one yet). >> >> This sounds like there might be a floating dependency in elfutils on >> bzip2, if its present. We probably need to lock that down one way or >> another. >> >>> Anyone else see this, or is it just another case of my build machines >>> being in a strange state? >> >> I've seen mesa-dri-glsl-native myself and if its the same issue, this is >> something the signature changes have highlighted. It was there before, >> that change just exposed it. >> >> Basically, the problem is compile running twice. You could do it before >> with something like: >> >> bitbake mesa-dri-glsl-native >> bitbake mesa-dri-glsl-native -c compile -f >> >> We either need to fix these makefile issues or run "make clean" against >> them before rerunning make. > > FWIW, I also had build failures on docbook-utils-native and libzypp. > In all cases a -c cleansstate and rebuild got me back to being > productive. I'm on a bit of a deadline so I didn't have time to > research a proper fix for each. > > The docbook-utils errors (and there were many) started with: > > | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" > for which no system identifier could be generated > | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here > | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" > for which no system identifier could be generated > | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here > | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" > for which no system identifier could be generated > | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here > > And the libzypp error: > > | /media/Work/yocto/tmp/sysroots/i686-linux/usr/bin/cmake -E > cmake_progress_report > /media/Work/yocto/tmp/work/omap3_multi-poky-linux-gnueabi/libzypp-0.0-git1+15b6c52260bbc52b3d8e585e271b67e10cc7c433-r18/git/CMakeFiles > | make[2]: *** No rule to make target > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libcrypto.so', > needed by `zypp/libzypp.so.810.1.0'. Stop. > > Sorry I don't have time to dig into the issues at the moment . . . Yet another FWIW - with another more "beefy" image the following failures occurred (both fixed with -c cleansstate and rebuild): font-util: | cp: cannot stat `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/share/aclocal/./audiofile.m4': No such file or directory NOTE: package font-util-1.2.0-r2.2: task do_configure: Failed ERROR: Task 3303 (/home/sakoman/source/yocto/poky/meta/recipes-graphics/xorg-font/font-util_1.2.0.bb, do_configure) failed with exit code '1' gcc: ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '/media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gcc-4.6.2+svnr181430-r27/gcc-4_6-branch/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/gcc' ERROR: Function failed: do_qa_configure ERROR: Logfile of failure stored in: /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gcc-4.6.2+svnr181430-r27/temp/log.do_configure.27718 NOTE: package gcc-4.6.2+svnr181430-r27: task do_configure: Failed No time to debug tonight, but thought I would mention them in case others run into them too. Steve ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: elfutils - missing dependency on bzip2? 2012-02-27 6:30 ` Steve Sakoman @ 2012-02-27 6:38 ` Martin Jansa 2012-02-27 14:25 ` Steve Sakoman 0 siblings, 1 reply; 6+ messages in thread From: Martin Jansa @ 2012-02-27 6:38 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 4561 bytes --] On Sun, Feb 26, 2012 at 10:30:04PM -0800, Steve Sakoman wrote: > On Sun, Feb 26, 2012 at 4:34 PM, Steve Sakoman <sakoman@gmail.com> wrote: > > On Sun, Feb 26, 2012 at 3:24 PM, Richard Purdie <rpurdie@rpsys.net> wrote: > >> On Sun, 2012-02-26 at 09:25 -0800, Steve Sakoman wrote: > >>> After a pull this morning the rebuild if elfutils fails with: > >>> > >>> | /usr/bin/ld: cannot find -lbz2 > >>> | collect2: ld returned 1 exit status > >>> | make[3]: *** [libdw.so] Error 1 > >>> | make[3]: Leaving directory > >>> `/media/Work/yocto/tmp/work/i686-linux/elfutils-native-0.148-r5/elfutils-0.148/libdw' > >>> > >>> If I build bzip2-native and then rebuild elfutils-native all is well > >>> and the build continues until the next failure (mesa-dri-glsl-native, > >>> fwiw, haven't investigated that one yet). > >> > >> This sounds like there might be a floating dependency in elfutils on > >> bzip2, if its present. We probably need to lock that down one way or > >> another. > >> > >>> Anyone else see this, or is it just another case of my build machines > >>> being in a strange state? > >> > >> I've seen mesa-dri-glsl-native myself and if its the same issue, this is > >> something the signature changes have highlighted. It was there before, > >> that change just exposed it. > >> > >> Basically, the problem is compile running twice. You could do it before > >> with something like: > >> > >> bitbake mesa-dri-glsl-native > >> bitbake mesa-dri-glsl-native -c compile -f > >> > >> We either need to fix these makefile issues or run "make clean" against > >> them before rerunning make. > > > > FWIW, I also had build failures on docbook-utils-native and libzypp. > > In all cases a -c cleansstate and rebuild got me back to being > > productive. I'm on a bit of a deadline so I didn't have time to > > research a proper fix for each. > > > > The docbook-utils errors (and there were many) started with: > > > > | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" > > for which no system identifier could be generated > > | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here > > | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" > > for which no system identifier could be generated > > | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here > > | jade:../../doc/docbook-utils.sgml:9:0:E: reference to entity "BOOK" > > for which no system identifier could be generated > > | jade:../../doc/docbook-utils.sgml:1:0: entity was defined here > > > > And the libzypp error: > > > > | /media/Work/yocto/tmp/sysroots/i686-linux/usr/bin/cmake -E > > cmake_progress_report > > /media/Work/yocto/tmp/work/omap3_multi-poky-linux-gnueabi/libzypp-0.0-git1+15b6c52260bbc52b3d8e585e271b67e10cc7c433-r18/git/CMakeFiles > > | make[2]: *** No rule to make target > > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libcrypto.so', > > needed by `zypp/libzypp.so.810.1.0'. Stop. > > > > Sorry I don't have time to dig into the issues at the moment . . . > > Yet another FWIW - with another more "beefy" image the following > failures occurred (both fixed with -c cleansstate and rebuild): > > font-util: > > | cp: cannot stat > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/share/aclocal/./audiofile.m4': > No such file or directory > NOTE: package font-util-1.2.0-r2.2: task do_configure: Failed > ERROR: Task 3303 > (/home/sakoman/source/yocto/poky/meta/recipes-graphics/xorg-font/font-util_1.2.0.bb, > do_configure) failed with exit code '1' > > gcc: > > ERROR: This autoconf log indicates errors, it looked at host include > and/or library paths while determining system capabilities. > Rerun configure task after fixing this. The path was > '/media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gcc-4.6.2+svnr181430-r27/gcc-4_6-branch/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/gcc' > ERROR: Function failed: do_qa_configure > ERROR: Logfile of failure stored in: > /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gcc-4.6.2+svnr181430-r27/temp/log.do_configure.27718 > NOTE: package gcc-4.6.2+svnr181430-r27: task do_configure: Failed Can you check config.log if it also has warning: "library search path "/usr/lib/cmplrs/cc2.11" is unsafe for cross-compilation" like in mine: http://paste.pocoo.org/show/541085/ ? I see this only when doing multimachine builds and removing sstate helps. Cheers, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: elfutils - missing dependency on bzip2? 2012-02-27 6:38 ` Martin Jansa @ 2012-02-27 14:25 ` Steve Sakoman 0 siblings, 0 replies; 6+ messages in thread From: Steve Sakoman @ 2012-02-27 14:25 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Martin Jansa On Sun, Feb 26, 2012 at 10:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> gcc: >> >> ERROR: This autoconf log indicates errors, it looked at host include >> and/or library paths while determining system capabilities. >> Rerun configure task after fixing this. The path was >> '/media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gcc-4.6.2+svnr181430-r27/gcc-4_6-branch/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/gcc' >> ERROR: Function failed: do_qa_configure >> ERROR: Logfile of failure stored in: >> /media/Work/yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gcc-4.6.2+svnr181430-r27/temp/log.do_configure.27718 >> NOTE: package gcc-4.6.2+svnr181430-r27: task do_configure: Failed > > Can you check config.log if it also has warning: > "library search path "/usr/lib/cmplrs/cc2.11" is unsafe for cross-compilation" > > like in mine: > http://paste.pocoo.org/show/541085/ Unfortunately I already did a -c cleansstate so the log from the failing build is gone :-( > I see this only when doing multimachine builds and removing sstate > helps. I had only done single MACHINE builds since doing a clean build last week. But removing sstate did fix the issue for me. Sorry I didn't investigate further, but I had a deadline to meet and didn't have time. I just wanted to document the errors so that if others encountered the same thing we would know it wasn't an isolated occurrence. Steve ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-27 14:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-26 17:25 elfutils - missing dependency on bzip2? Steve Sakoman 2012-02-26 23:24 ` Richard Purdie 2012-02-27 0:34 ` Steve Sakoman 2012-02-27 6:30 ` Steve Sakoman 2012-02-27 6:38 ` Martin Jansa 2012-02-27 14:25 ` Steve Sakoman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox