[OE-core] elfutils - missing dependency on bzip2?

Steve Sakoman sakoman at gmail.com
Mon Feb 27 06:30:04 UTC 2012


On Sun, Feb 26, 2012 at 4:34 PM, Steve Sakoman <sakoman at gmail.com> wrote:
> On Sun, Feb 26, 2012 at 3:24 PM, Richard Purdie <rpurdie at 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




More information about the Openembedded-core mailing list