native recipe and sysroot-destdir troubles

Yocto,

I'm working on two new recipes and both are working quite well. Now I need native variants and online sources indicate this should be done through BBCLASSEXTEND = "native". For one of my recipes this works fine, for the other not so much.

The error I'm seeing seems to be in the staging of the sysroot-destdir which ends up being empty though the source code builds fine (image directory has everything expected). do_populate_sysroot seems to assume there's a directory structure present which ends up being empty causing an error when it trys to tar the directory up. If I create the directories do_populate_sysroot expects the recipe runs to completion but sysroot-destdir still ends up being empty and no packages are built.

Given that one of my packages works fine I'd guess the problem lies in the Makefiles for the offending source tree and not yocto though I'm still unsure of how to move forward. Any help would be appreciated. I can pastebin the receips if that will help.

TIA,
- Philip

P.S. OE Build Configuration:

BB_VERSION        = "1.13.3"
TARGET_ARCH       = "i586"
TARGET_OS         = "linux"
MACHINE           = "qemux86"
DISTRO            = "poky"
DISTRO_VERSION    = "1.1"
TUNE_FEATURES     = "m32 i586"
TARGET_FPU        = ""

meta
meta-yocto = "<unknown>:<unknown>"

More / better info:

Image directiory is populated as expected (has lib, usr/include etc with expected files). Build is failing on populate_sysroot:

CalledProcessError: Command 'tar -cf - -C /home/build/poky-edison-6.0/build/tmp/work/i686-linux/libmylib-native-2.1.4-r0/sysroot-destdir///home/build/poky-edison-6.0/build/tmp/sysroots/i686-linux -ps . | tar -xf - -C
/home/build/poky-edison-6.0/build/tmp/sysroots/i686-linux' returned
non-zero exit status 2 with output tar:
/home/build/poky-edison-6.0/build/tmp/work/i686-linux/libmylib-native-2.1.4-r0/sysroot-destdir///home/build/poky-edison-6.0/build/tmp/sysroots/i686-linux:
Cannot chdir: No such file or directory
tar: Error is not recoverable: exiting now

The failure is obviously due to sysroot-destdir being empty. The question is why this directory is populated for libmylib but not for libmylib-native ... they're built from the same recipe.

Stack trace:

ERROR: The stack trace of python calls that resulted in this exception/failure was:
ERROR: File "sstate_task_postfunc", line 10, in <module>
ERROR:
ERROR: File "sstate_task_postfunc", line 4, in sstate_task_postfunc
ERROR:
ERROR: File "sstate.bbclass", line 19, in sstate_install
ERROR:
ERROR: File "/home/build/poky-edison-6.0/meta/lib/oe/path.py", line
59, in copytree
ERROR: check_output(cmd, shell=True, stderr=subprocess.STDOUT)
ERROR:
ERROR: File "/home/build/poky-edison-6.0/meta/lib/oe/path.py", line
121, in check_output
ERROR: raise CalledProcessError(retcode, cmd, output=output)
ERROR:

ERROR: The code that was being executed was:
ERROR:      0006:        bb.build.exec_func(intercept, d)
ERROR:      0007:    sstate_package(shared_state, d)
ERROR:      0008:
ERROR:      0009:
ERROR:  *** 0010:sstate_task_postfunc(d)
ERROR:      0011:
ERROR: (file: 'sstate_task_postfunc', lineno: 10, function: <module>)
ERROR:      0001:
ERROR:      0002:def sstate_task_postfunc(d):
ERROR:      0003:    shared_state = sstate_state_fromvars(d)
ERROR:  *** 0004:    sstate_install(shared_state, d)
ERROR:      0005:    for intercept in shared_state['interceptfuncs']:
ERROR:      0006:        bb.build.exec_func(intercept, d)
ERROR:      0007:    sstate_package(shared_state, d)
ERROR:      0008:
ERROR: (file: 'sstate_task_postfunc', lineno: 4, function:

sstate_task_postfunc)
ERROR: Function 'sstate_task_postfunc' failed

Thanks,
- Philip

Worked out a solution to this issue. For the sake of brevity it can be found here:

http://twobit.us/blog/2012/04/openembedded-yocto-native-hello-world/

Cheers,
- Philip

So just to follow up here too for the list archives:

This “craziness” does have a rational explanation. “native” targets are meant to run on the system they’re built on and run in the location they’re installed to. This means they install to a destination of “/” and PREFIX is inside the native sysroot directory.

We install them to a DESTDIR to allow us to manipulate them before they then get moved to a final DESTDIR of “/”.

Most Makefiles handle this correctly by doing:

DESTDIR ?= “”
prefix ?= “/usrr”
bindir ?= “$(prefix)/bin”

and then, importantly, install in the form:

install -d $(DESTDIR)$(bindir)

so both prefix and DESTDIR are used. Whilst this is a convention, its a widely adopted and followed one. As you’ve found, you can call into a custom makefile and set the variables manually if the makefile doesn’t follow the convention.

Cheers,

Richard