[bitbake-devel] Bitbake for native x86 project?

[Richard Purdie]

On Sun, 2013-10-13 at 17:53 +0100, Richard Purdie wrote:

> Its certainly possible, its just that nobody has done it. Your options
> would be to either reconfigure the native recipes to be packaged, or to
> add in a configuration which shortcircuits the cross compiler and adds
> in some native magic to specific machine targets.
> 
> Whilst adding packaging to native sounds attractive, the reality is that
> its not easy and doesn't really make sense technically. Adding in those
> short-circuits I mention by comparison shouldn't be hard and if I were
> doing this, its the way I'd go.

I had a kind of morbid curiosity about this. I came up with the patches
here:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=c1c02d166f22179fb18e430aeae2806bb5d51a3f

where I've basically tried to wire in the host gcc yet compile
everything else for the target as usual including the libc. Its a bit of
an arbitrary choice but should in theory be easier than providing a
whole libc from the native system.

It works to a point (e.g. gettext compiled) but ncurses did not due to
symbol errors with __poll_chk. Why? Basically the compiler/linker do not
respect the sysroot, go searching for libc and find the system one
rather than the one we built. It then fails to link as there is version
mismatch. There isn't any compiler commandline option you can tweak to
stop it doing this :(.

Some questions this raises:

a) Do you use a sysroot of "/" or STAGING_DIR_TARGET?

I did the latter, it wasn't particularly successful as the tools don't
all respect it properly. In theory you can link the pieces inside the
STAGING_DIR to outside the sysroot if you want the compiler to see them,
the reality is some search paths are hardcoded into gcc and they leak
in. When we compile our compiler, we configure it not to do that.

To use "/" you'd have to do what native.bbclass does, set
STAGING_DIR_TARGET to be "/" and then set prefix to be inside the
STAGING_DIR but this means that binaries would expect to always run with
such a prefix.

I guess a hybrid would be possible, add -L and -I for the sysroot and
accept it linking with the system lib/include directories, ditching the
sysroot option a bit like the system did before gcc has sysroot support.

b) Can you use the system compiler without the libc?

Answer appears to be no, you can't. This means you would have to add in
some kind of tweaking to the output packages to add in dependencies on
libc and anything else that was system provided. You can therefore not
use this approach to build complete systems. Packaging up the system
provided libc would also seem to be ruled out.

Cheers,

Richard