elfutils - missing dependency on bzip2?

elfutils - missing dependency on bzip2?

[Steve Sakoman]

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

Re: elfutils - missing dependency on bzip2?

[Richard Purdie]

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

Re: elfutils - missing dependency on bzip2?

[Steve Sakoman]

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

Re: elfutils - missing dependency on bzip2?

[Steve Sakoman]

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

Re: elfutils - missing dependency on bzip2?

[Martin Jansa]

[-- 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 --]

Re: elfutils - missing dependency on bzip2?

[Steve Sakoman]

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