All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Garman <scott.a.garman@intel.com>
To: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: When is it ok to link to host libraries?
Date: Mon, 22 Nov 2010 11:01:53 -0800	[thread overview]
Message-ID: <4CEABE21.40406@intel.com> (raw)

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


             reply	other threads:[~2010-11-22 19:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 19:01 Scott Garman [this message]
2010-11-22 19:09 ` When is it ok to link to host libraries? Mark Hatle
2010-11-22 20:34 ` Stewart, David C

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CEABE21.40406@intel.com \
    --to=scott.a.garman@intel.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.