Date 1 - 2 of 2
Questions based on sysroot testing
|1 - 2 of 2|
As we'll allow dynamic setup sysroot for app developers, I've done some testing and here are some findings that want to further discuss with you:
1. We talked about using qemu rootfs as target sysroot, some I've tried pass "--sysroot" to cross gcc and tested against one of our existing testing app, cvs. The cvs project client.c is using gssapi.h, with the sysroot option, it'll strictly looking for target include within the sysroot setup, so it failed at finding "gssapi.h". While our original sysroots under /opt/poky, even we don't have gssapi.h under our sysroot, but since we're not using --sysroot option to enforce searching target libraries and include files, it was able to use the gssapi.h under /usr/include/gssapi. My question here is which one is the desired behavior, the --sysroot enforcement which means we/user need to include everything needed in the sysroot, or the current /opt/poky sysroot behavior that uses the host setting as the 2nd choice...
2. Under our /opt/poky/sysroot, we have target sysroot(e.g. i586-poky-linux), and host sysroot (i586-pokysdk-linux), for the user sysroot setup, I don't think we need to copy the host sysroot under the usr sysroort setup dir, seems for the specific arch, the host sysroot will be fixed, only the target sysroot may change even for the same target arch which we'll use target qemu rootfs, is this correct?
Richard Purdie <rpurdie@...>
On Mon, 2010-11-15 at 12:05 -0800, Zhang, Jessica wrote:
As we'll allow dynamic setup sysroot for app developers, I've doneThis is desired behaviour, you should *never* be mixing host and target
system headers or libraries. The current behaviour is plain wrong and if
I'd known it was doing that, I'd have fixed it before now ;-).
2. Under our /opt/poky/sysroot, we have target sysroot(e.g.This is correct.
|1 - 2 of 2|