Date
1 - 3 of 3
When is it ok to link to host libraries?
|
Scott Garman <scott.a.garman@...>
Hello,
I'd like to get some better clarity about what constitutes host contamination when it comes to building packages. Could someone with deeper knowledge of these issues clarify or comment on the following? My understanding is that when building non -native recipes, there should be absolutely no linking to the libraries on the host system - meaning that autotols configure scripts and so on should not be determining which features are available based on what packages are installed on the host OS. The only exceptions to this are the use of some core system utilities (cp, mv, etc). However, when it comes to -native recipes, is it acceptable to link to the host libraries? Since the package is intended to run on the same host, I would think this would be acceptable, but I'm not certain. The problem I'm working on which prompted this inquiry is a segfault that is occurring with QEMU in certain circumstances. The latest Ubuntu (10.10, Maverick) with the proprietary NVIDIA Xorg driver also installs its own version of libGL, which is linked by qemu-native. If I uninstall the proprietary NVIDIA driver and rebuild qemu-native from scratch, the segfault does not occur. Thanks, Scott -- Scott Garman Embedded Linux Distro Engineer - Yocto Project |
|
|
|
Mark Hatle <mark.hatle@...>
On 11/22/10 1:01 PM, Scott Garman wrote:
Hello,In general this is true.... however there are cases where a helper application needs to be built, i.e. to generate a structure list... to compile some specialized code, etc.. This can use the host system's compiler and libraries.. but needs to be closely monitored to make sure it won't introduce other host-system contamination. (Usually BUILD_CC or HOST_CC is used instead of the regular CC). However, when it comes to -native recipes, is it acceptable to link toDepends, if the item being linked to is part of the Poky -native recipes it should be just fine. If it's part of the host system itself, we need to decide if it's a "common enough", or a Poky host system requirement. If so, then we can generally link to it.. if it doesn't fall into either of those categories, then we need to evaluate if the item should have a -native added for it, should it be added to the poky requirements, or is it "an exception" for some other reason. The problem I'm working on which prompted this inquiry is a segfaultThats not surprising. Generally applications will link to the mesa libGL/libGLU drivers. Then an optimized version will replace it and assume it's API and functionality. My guess is there is a difference in the way the item is linked -- or the symbols are resolved between the NVIDIA and the non-NVIDIA version. (likely a compatibility defect in the proprietary version...) Something like weak or aliased symbol resolution might be the cause... Either way, I'd recommend we document these, and if it's truly a host system issue we add a list of know problems. (In this particular case, I'd consider the mesa GL interface to be a "required host component", if we have graphics enabled in QEMU. Since the host's version is broken.. a documented way to identify the failure and how to work around it is likely a very good idea... perhaps even adding something to the Poky host checking classes might be reasonable in this case -- or alternatively to the QEMU-native build.. have it verify it won't be building a broken version.) --Mark Thanks, |
|
|
|
David Stewart
From: yocto-bounces@... [mailto:yocto-Would you ever have a situation where you build the SDK on one distro version but install and use it on another one? If so, does this affect your decisions? Thanks, |
|
|