| Summary: | make menuconfig fails in the sdk and esdk. | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] eSDK | Reporter: | brian avery <brian.avery> |
| Component: | eSDK | Assignee: | Saul Wold <sgw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | bluelightning |
| Version: | 2.3 | ||
| Target Milestone: | 2.4 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
brian avery
2017-03-14 18:06:53 UTC
Saul said he would look at this. Adding nativesdk-ncurses to nativesdk-packagegroup-sdk-host.bb is not sufficient because the check-lxdiaog.sh uses $cc for its test and it seems to be stripping things like CC of the sysroot, The issue revolves around the use of pkg-config. In the sdk and esdk we have *2* pkg-configs. pkg-config (intended for use by builds for the target) and pkg-config-native (intended or use by host tools aka native tools) . In the kernel, it uses pkg-config to determine the location of libncurses. Since it calls pkg-config, it gets the information for the target sysroot and things break. If you patch the kernel (in scripts/kconfig/lxdialog/check-lxdialog.sh) and change pkg-congig to pkg-config-native, everything works fine. A different workaround is to run make menuconfig in a non-sdk enabled shell environment and then do the actual kernel build (aka for the target) in the sdk enabled shell environment. This way, menuconfig would get the host libs and the kernel builds would get the target libs. This is *NOT* easy or even possible to fix in general. We need some documentation explaining the issue clearly and outlining the solutions. For cases where the code we are trying to build with the sdk/esdk uses pkg-config to enable both host side builds and target side builds; we are stuck. The kernel is a simple example of this since it does it in 2 separable steps. Some pkgs use host side tools to generate source code that is then built for the target. These would also have issues. Note that in the sdk/esdk we are building code and not necessarily building recipes that we have patched to work around this issue... Noting this also, we need to extend the required host installed packages to include the ncurses-devel for the workaround to work correctly. nope, not needed. if we change pkg-config to pkg-config-native in scripts/kconfig/lxdialog/check-lxdialog.sh , it uses the curses.h from the sdk . verified in an ubuntu 16.04 container w/o curses-devel installed. A couple of additional ideas: 1) use devtool kernel menuconfig -- this could easily hide the -native or not -- *requires* kernel devs to use devtool, which I think is a bad idea. -- i kinda think the only thing devtool should do with the kernel in the esdk is to extract it and its config. everything else should be natural flow. 2) turn pkg-config into a bash script and have it check to see who is calling it and vector to the "right" pkg-config. Right now, the kernel lx0check-curses.sh is the only instance in which we need -native. This is a tad hacky but the fact that we are using a tool not made for cross in this way kinda mitigates that. Would be easy to add additional "native caller's" if the pkg-config script read them in from a regex-file. 3) upstream a patch to the kernel so that if some env variables were set to provide the correct ncurses libs and args, the kernel wouldn't look for the "right" ncurses setup, it would just use the ones you gave it. Call it the Do tell,Don't ask patch :) |