From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: stubdom: build failure Date: Wed, 24 Sep 2008 16:43:34 +0200 Message-ID: <200809241643.35218.Christoph.Egger@amd.com> References: <200809241621.22646.Christoph.Egger@amd.com> <20080924143558.GO4527@implementation.bordeaux.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20080924143558.GO4527@implementation.bordeaux.inria.fr> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Samuel Thibault Cc: xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org On Wednesday 24 September 2008 16:35:58 Samuel Thibault wrote: > Keir Fraser, le Wed 24 Sep 2008 15:31:13 +0100, a =E9crit : > > If it's due to pulling in too many /usr/include headers then perhaps > > we could copy the ones we actually need into a private local directory > > and add that to the search path instead? I guess it depends if those > > headers themselves #include any more; then it'd get messy. If they're > > compiler intrinsics then perhaps they won't. > > In principles we only needs files that declare compiler intrinsics. On NetBSD, compiler intrinsics don't exist. I think, it's better to put an OS abstraction into stubdom where only the Linux specific code uses compiler intrinsics and other Linux-only= =20 stuff. If you try (hard) to make every OS look like Linux instead, things become=20 messy. Christoph =2D-=20 AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Gesch=E4ftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplement=E4r: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Gesch=E4ftsf=FChrer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy