Bug 2193 - systemtap build fails: docproc: cannot execute binary file
Summary: systemtap build fails: docproc: cannot execute binary file
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: kernel (show other bugs)
Version: unspecified
Hardware: All Multiple
: High critical
Target Milestone: 1.2 M4
Assignee: Tom Zanussi
QA Contact:
URL:
Whiteboard: (1.2)(patch submitted for review)
Depends on:
Blocks:
 
Reported: 2012-03-29 10:37 UTC by Wolfgang Denk
Modified: 2012-04-14 14:30 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Denk 2012-03-29 10:37:53 UTC 
Building "systemtap" fails with errors like:

| SRCTREE=/opt/eldk/build/1.2_M4.rc1-2012-03-28-4d9f4d6-beagleboard/tmp/work/armv5te-poky-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r2/git/ /opt/eldk/build/1.2_M4.rc1-2012-03-28-4d9f4d6-beagleboard/tmp/work/armv5te-poky-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r2/git/doc/SystemTap_Tapset_Reference/docproc doc /opt/eldk/build/1.2_M4.rc1-2012-03-28-4d9f4d6-beagleboard/tmp/work/armv5te-poky-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r2/git/doc/SystemTap_Tapset_RERROR: Function failed: do_compile (see /opt/eldk/build/1.2_M4.rc1-2012-03-28-4d9f4d6-beagleboard/tmp/work/armv5te-poky-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r2/temp/log.do_compile.23964 for further information)
| eference/tapsets.tmpl > tapsets.xml.new
| /bin/sh: /opt/eldk/build/1.2_M4.rc1-2012-03-28-4d9f4d6-beagleboard/tmp/work/armv5te-poky-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r2/git/doc/SystemTap_Tapset_Reference/docproc: cannot execute binary file
| make[3]: *** [tapsets.xml] Error 126

As far as I can see the results of the autobuilder are misleading - it
works only because these do not contain the documentation part.

This appears to be a tricky (as non-obvious) dependency on the build
environment.  The systemtap configure script uses this code:

if test "x${have_latex}${have_dvips}${have_ps2pdf}${have_latex2html}" == "xyesyesyesyes" -a "$enable_docs" != "no"; then
   building_docs="yes"
fi

I guess one or more of the packages tested here (latex, dvips, ps2pdf,
latex2html) is not installed on the autobuilder, so building works,
but without documentation.

I have all thse packages installed on my build host, and building
fails.

A potential workaround would be to _always_ disable the generation of
the documentation (disable BUILD_REFDOCS); of course it would even be
better to fix the build issue.
Comment 1 Darren Hart 2012-03-29 23:08:36 UTC 
Wolfgang,

Can you provide the build info from bitbake at the start of the build (layer HEADs, MACHINE, and target in particular).

Tom, have you experienced this? Assuming not.
Comment 2 Tom Zanussi 2012-03-29 23:11:18 UTC 
No, I haven't ever seen this.
Comment 3 Tom Zanussi 2012-03-30 03:53:40 UTC 
I this using qemux86, enabling tools-profile and installing all the documentation packages systemtap was looking for.

It's correct that that the build will succeed but without documentation if one or more of the needed packages are there.

On my system (Ubuntu 10.04), the necessary packages were missing and the build succeeded though the documentation wasn't built as do_configure didn't find all the packages ans skipped it:

checking for latex... no
checking for dvips... no
checking for ps2pdf... yes
checking for latex2html... no
configure: WARNING: will not build documentation, cannot find all tools

When I installed texlive and latex2html on my Ubuntu system, the docs
build succeded, but they weren't built in pdf format again because of
missing packages.

checking for sqlite3_open in -lsqlite3... yes
checking for latex... yes
checking for dvips... yes
checking for ps2pdf... yes
checking for latex2html... yes
checking for publican... no
checking for xmlto... yes
checking for xmlto --stringparam support... yes
checking for xmlto pdf support... no
configure: WARNING: Not building reference documentation in PDF format

At this point, I don't have xmlto pdf support because the xmlto in Ubuntu doesn't have pdf support and apparently that's because the upstream package that relies on has been abandonded (passivetex).

So I'm not yet able to reproduce this - it looks like the original problem was seen building an arm target, maybe I'll try that.
Comment 4 Wolfgang Denk 2012-03-30 06:44:35 UTC 
(In reply to comment #1)
> Wolfgang,
> 
> Can you provide the build info from bitbake at the start of the build (layer
> HEADs, MACHINE, and target in particular).

This is a plain build of 1.2_M4.rc1 for the "qemuarm" machine:

OE Build Configuration:
BB_VERSION        = "1.15.1"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "qemuarm"
DISTRO            = "poky"
DISTRO_VERSION    = "1.1+snapshot-20120329"
TUNE_FEATURES     = "armv5 dsp thumb arm926ejs"
TARGET_FPU        = "soft"
meta              
meta-yocto        = "1.2_M4.rc1:4d9f4d6ac25f39fe6d5491d05c7a26195bab648b"

The same happens when building for MACHINE="beagleboard".
Comment 5 Wolfgang Denk 2012-03-30 06:50:30 UTC 
(In reply to comment #3)
> I this using qemux86, enabling tools-profile and installing all the
> documentation packages systemtap was looking for.
> 
> It's correct that that the build will succeed but without documentation if one
> or more of the needed packages are there.

I guess you mean "...are NOT there" ?

> So I'm not yet able to reproduce this - it looks like the original problem was
> seen building an arm target, maybe I'll try that.

You don't see the problem because host and target architecture are
the same, so you can execute the generated
".../doc/SystemTap_Tapset_Reference/docproc" binary.  I'm building on
a x86_64 host for an ARM target, and I get:

| /bin/sh: /opt/eldk/build/1.2_M4.rc1-2012-03-28-4d9f4d6-beagleboard/tmp/work/armv5te-poky-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r2/git/doc/SystemTap_Tapset_Reference/docproc: cannot execute binary file

This is no big surprise:

-> file /opt/eldk/build/1.2_M4.rc1-2012-03-28-4d9f4d6-beagleboard/tmp/work/armv5te-poky-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r2/git/doc/SystemTap_Tapset_Reference/docproc
/opt/eldk/build/1.2_M4.rc1-2012-03-28-4d9f4d6-beagleboard/tmp/work/armv5te-poky-linux-gnueabi/systemtap-1.7+git1+83bd2699d8cff2f2d6b9eaf5ea254e4cb6b33e81-r2/git/doc/SystemTap_Tapset_Reference/docproc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped

Trying to run the ARM binary on the x86 host causes the "cannot
execute binary file" error.
Comment 6 Tom Zanussi 2012-04-10 14:33:49 UTC 
An update - the problem is that docproc is being built for the target, but needs to be build for the host.  First attempt before having to move on to other things was to try getting just the docproc alone built using ${BUILD_CC} ${BUILD_CFLAGS}, which didn't work on the first try.