From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoph Egger <Christoph.Egger@amd.com>
Subject: Re: stubdom: build failure
Date: Wed, 24 Sep 2008 16:21:22 +0200
Message-ID: <200809241621.22646.Christoph.Egger@amd.com>
References: <C500047A.27708%keir.fraser@eu.citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <C500047A.27708%keir.fraser@eu.citrix.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>, Keir Fraser <keir.fraser@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Wednesday 24 September 2008 15:51:38 Keir Fraser wrote:
> On 24/9/08 14:39, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> >> Uh, it's odd that -print-search-dirs doesn't provide the install one.
> >> Does gcc -print-file-name=3Dinclude/stddef.h provide the correct path?
> >
> > No. gcc -print-file-name=3Dblah  works like  echo blah
> > On NetBSD there are only system libs and headers.
> >
> > On NetBSD stddef.h is in /usr/include/  as well as
> > stdarg.h, stdbool.h, etc.
>
> Could we perhaps force GCC_INSTALL to /usr/include on BSD systems? Or if
> GCC_INSTALL is empty after executing the current shell runes?
>
> Can you check forcing GCC_INSTALL=3D/usr/include works? I assume it might
> cause us to put more headers in the search path than we'd like.

Since the buildsystem appends include automatically, I tested with
forcing GCC_INSTALL=3D"/usr/"

This fixed the problem about not finding stddef.h , but shows
other errors then:


In file included from /usr/include/sys/time.h:38,
                =20
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/sys/tim=
e.h:24,
                =20
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os=
/time.h:49,
                =20
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os=
/sched.h:5,
                =20
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/errno.h=
:116,
                =20
from ../../../../../newlib-1.16.0/newlib/libc/argz/argz_add.c:7:
/usr/include/sys/types.h:286: error: conflicting types for 'time_t'
/build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/time=
=2Eh:46:=20
error: previous declaration of 'time_t' was here
/usr/include/sys/types.h:301: error: conflicting types for 'suseconds_t'
/build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/time=
=2Eh:47:=20
error: previous declaration of 'suseconds_t' was here
[...]

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