stubdom: build failure

stubdom: build failure

[Christoph Egger]

[-- Attachment #1: Type: text/plain, Size: 3263 bytes --]


In extras/mini-os/include/types.h, line 22 tries to include stddef.h .
But this file doesn't exist and due to use of -nostdinc the libc's stddef.h
isn't used/found.

On NetBSD, this leads to this build error:

gmake[6]: Entering directory 
`/build/xen-staging-netbsd.hg/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/argz' 
gcc -isystem /root/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/posix -isystem /build/xen-staging-netbsd.hg/stubdom/../tools/xenstore  -isystem /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/x86 -isystem /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/x86/x86_64 -U__linux__ -U__FreeBSD__ -U__sun__ -nostdinc -isystem /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/posix -isystem /build/xen-staging-netbsd.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem 
include -isystem /build/xen-staging-netbsd.hg/stubdom/lwip-x86_64/src/include -isystem /build/xen-staging-netbsd.hg/stubdom/lwip-x86_64/src/include/ipv4 -I/build/xen-staging-netbsd.hg/stubdom/include -mno-red-zone -O0 -fno-omit-frame-pointer -fno-optimize-sibling-calls  -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement   -fno-stack-protector  -D_I386MACH_ALLOW_HW_INTERRUPTS -B/build/xen-staging-netbsd.hg/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/ -isystem /build/xen-staging-netbsd.hg/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/targ-include -isystem /build/xen-staging-netbsd.hg/stubdom/newlib-1.16.0/newlib/libc/include -B/build/xen-staging-netbsd.hg/stubdom/newlib-x86_64/x86_64-xen-elf/libgloss/x86_64 -L/build/xen-staging-netbsd.hg/stubdom/newlib-x86_64/x86_64-xen-elf/libgloss/libnosys -L/build/xen-staging-netbsd.hg/stubdom/newlib-1.16.0/libgloss/x86_64 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.16.0\" -DPACKAGE_STRING=\"newlib\ 
1.16.0\" -DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../newlib-1.16.0/newlib/libc/argz -O2 -DMISSING_SYSCALL_NAMES -fno-builtin      -O2 -g -g -O2   -c -o 
lib_a-argz_add.o `test -f 'argz_add.c' || 
echo '../../../../../newlib-1.16.0/newlib/libc/argz/'`argz_add.c
In file included 
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/time.h:22,
                 
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/sched.h:5,
                 
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/errno.h:116,
                 
from ../../../../../newlib-1.16.0/newlib/libc/argz/argz_add.c:7: /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/types.h:22:20: 
error: stddef.h: No such file or directory




-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: stubdom: build failure

[Samuel Thibault]

Hello,

Christoph Egger, le Wed 24 Sep 2008 14:25:07 +0200, a écrit :
> In extras/mini-os/include/types.h, line 22 tries to include stddef.h .
> But this file doesn't exist

It should in the gcc include/ path.

> and due to use of -nostdinc the libc's stddef.h isn't used/found.

That's on purpose.

> gcc <snip> -isystem include

It looks like $(GCC_INSTALL) is empty, that's your issue.

Samuel

Re: stubdom: build failure

[Christoph Egger]

On Wednesday 24 September 2008 14:33:32 Samuel Thibault wrote:
> Hello,
>
> Christoph Egger, le Wed 24 Sep 2008 14:25:07 +0200, a écrit :
> > In extras/mini-os/include/types.h, line 22 tries to include stddef.h .
> > But this file doesn't exist
>
> It should in the gcc include/ path.
>
> > and due to use of -nostdinc the libc's stddef.h isn't used/found.
>
> That's on purpose.
>
> > gcc <snip> -isystem include
>
> It looks like $(GCC_INSTALL) is empty, that's your issue.

In stubdom/Makefile I found this line:

GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: 
\(.*\)/\1/p')

# gcc -print-search-dirs
programs: =/usr/libexec/
libraries: =/usr/lib/
#

the sed expression empties GCC_INSTALL then.



-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: stubdom: build failure

[Samuel Thibault]

Hello,

Christoph Egger, le Wed 24 Sep 2008 14:40:50 +0200, a écrit :
> # gcc -print-search-dirs
> programs: =/usr/libexec/
> libraries: =/usr/lib/
> #

Ouch...  Which version of gcc is that?  We need a way to determine
where the gcc-intrisic headers live (usually something like
/usr/lib/gcc/i486-linux-gnu/4.3.1/)

Samuel

Re: stubdom: build failure

[Christoph Egger]

On Wednesday 24 September 2008 14:48:48 Samuel Thibault wrote:
> Hello,
>
> Christoph Egger, le Wed 24 Sep 2008 14:40:50 +0200, a écrit :
> > # gcc -print-search-dirs
> > programs: =/usr/libexec/
> > libraries: =/usr/lib/
> > #
>
> Ouch...  Which version of gcc is that?

# gcc -v
Using built-in specs.
Target: x86_64--netbsd
Configured 
with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=x86_64-unknown-netbsd4.99.72 --host=x86_64--netbsd --target=x86_64--netbsd --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.3 20080704 prerelease (NetBSD nb1 20080202)
#

> We need a way to determine where the gcc-intrisic headers live (usually
> something like /usr/lib/gcc/i486-linux-gnu/4.3.1/)
>
> Samuel



-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: stubdom: build failure

[Samuel Thibault]

Christoph Egger, le Wed 24 Sep 2008 14:57:41 +0200, a écrit :
> # gcc -v
> Using built-in specs.
> Target: x86_64--netbsd
> Configured 
> with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=x86_64-unknown-netbsd4.99.72 --host=x86_64--netbsd --target=x86_64--netbsd --enable-__cxa_atexit
> Thread model: posix
> gcc version 4.1.3 20080704 prerelease (NetBSD nb1 20080202)

Uh, it's odd that -print-search-dirs doesn't provide the install one.
Does gcc -print-file-name=include/stddef.h provide the correct path?

Samuel

Re: stubdom: build failure

[Christoph Egger]

On Wednesday 24 September 2008 15:13:03 Samuel Thibault wrote:
> Christoph Egger, le Wed 24 Sep 2008 14:57:41 +0200, a écrit :
> > # gcc -v
> > Using built-in specs.
> > Target: x86_64--netbsd
> > Configured
> > with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long
> > --disable-multilib --enable-threads --disable-symvers
> > --build=x86_64-unknown-netbsd4.99.72 --host=x86_64--netbsd
> > --target=x86_64--netbsd --enable-__cxa_atexit Thread model: posix
> > gcc version 4.1.3 20080704 prerelease (NetBSD nb1 20080202)
>
> Uh, it's odd that -print-search-dirs doesn't provide the install one.
> Does gcc -print-file-name=include/stddef.h provide the correct path?

No. gcc -print-file-name=blah  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.

Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: stubdom: build failure

[Samuel Thibault]

Christoph Egger, le Wed 24 Sep 2008 15:39:25 +0200, a écrit :
> On Wednesday 24 September 2008 15:13:03 Samuel Thibault wrote:
> > Uh, it's odd that -print-search-dirs doesn't provide the install one.
> > Does gcc -print-file-name=include/stddef.h provide the correct path?
> 
> No. gcc -print-file-name=blah  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.

Ah...  Well then the only way is to build a cross-compilation chain, as
was done before changetset 17969:433d1b26fd51 :/

Samuel

Re: stubdom: build failure

[Keir Fraser]

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=include/stddef.h provide the correct path?
> 
> No. gcc -print-file-name=blah  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=/usr/include works? I assume it might
cause us to put more headers in the search path than we'd like.

 -- Keir

Re: stubdom: build failure

[Christoph Egger]

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=include/stddef.h provide the correct path?
> >
> > No. gcc -print-file-name=blah  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=/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="/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,
                 
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/sys/time.h:24,
                 
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/time.h:49,
                 
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/sched.h:5,
                 
from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/errno.h:116,
                 
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.h:46: 
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.h:47: 
error: previous declaration of 'suseconds_t' was here
[...]

Christoph


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: stubdom: build failure

[Samuel Thibault]

Keir Fraser, le Wed 24 Sep 2008 14:51:38 +0100, a écrit :
> 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=include/stddef.h provide the correct path?
> > 
> > No. gcc -print-file-name=blah  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=/usr/include works?

Please do yes, and if it works then great.

> I assume it might cause us to put more headers in the search path than
> we'd like.

In principle the mini-os ones should get before that, but at least by
including stddef.h and such we might pull libc headers and thus pull
compilation issues. Let's see.

Samuel

Re: stubdom: build failure

[Keir Fraser]

On 24/9/08 15:21, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

>> 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=/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="/usr/"
> 
> This fixed the problem about not finding stddef.h , but shows
> other errors then:

Hopefully Samuel has an idea what's going on here. 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.

 -- Keir

Re: stubdom: build failure

[Samuel Thibault]

Christoph Egger, le Wed 24 Sep 2008 16:21:22 +0200, a écrit :
> In file included from /usr/include/sys/time.h:38,
>                  
> from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/sys/time.h:24,
>                  
> from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/time.h:49,
>                  
> from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/mini-os/sched.h:5,
>                  
> from /build/xen-staging-netbsd.hg/stubdom/../extras/mini-os/include/errno.h:116,
>                  
> 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.h:46: 
> 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.h:47: 
> error: previous declaration of 'suseconds_t' was here

That's the kind of things I was afraid of.  However it's odd: newlib's
sys/time.h should get included before /usr/include's since the isystem
option for it is before...

Samuel

Re: stubdom: build failure

[Samuel Thibault]

Keir Fraser, le Wed 24 Sep 2008 15:31:13 +0100, a écrit :
> 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.

Samuel

Re: stubdom: build failure

[Christoph Egger]

On Wednesday 24 September 2008 16:35:58 Samuel Thibault wrote:
> Keir Fraser, le Wed 24 Sep 2008 15:31:13 +0100, a écrit :
> > 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 
stuff.
If you try (hard) to make every OS look like Linux instead, things become 
messy.

Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy

Re: stubdom: build failure

[Samuel Thibault]

Christoph Egger, le Wed 24 Sep 2008 16:43:34 +0200, a écrit :
> On Wednesday 24 September 2008 16:35:58 Samuel Thibault wrote:
> > Keir Fraser, le Wed 24 Sep 2008 15:31:13 +0100, a écrit :
> > > 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 
> stuff.
> If you try (hard) to make every OS look like Linux instead, things become 
> messy.

That's not the problem. We already do make mini-os have its own
definitions etc.  What we don't want to do is to define things like
stdarg.h and such, thus including these gcc headers (what we call gcc
intrinsics).  Before cs 17969:433d1b26fd51, we were not using the host
headers and compiler at all and building a full cross-compilation
environment instead; but that takes quite some time, while we already
have a compiler on the host...

Samuel

Re: stubdom: build failure

[Keir Fraser]

On 24/9/08 15:43, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

>> In principles we only needs files that declare compiler intrinsics.
> 
> On NetBSD, compiler intrinsics don't exist.

Well, whatever you call them, if the few files we need to pull in from the
environment are self-contained, we can simply copy them to a private
directory and point the search path there. Can you try that out? If it works
then making a small shell fragment to do this automatically for NetBSD would
be pretty easy.

 -- Keir

Stubdom build failure

[Neo Jia]

hi,

Not sure if anybody else encounter this problem or not with TIP unstable branch.

make[2]: *** No rule to make target
`/home/cjia/scratch/workareas/vtd/xen-unstable-latest.hg/stubdom/ioemu/i386-stubdom/qemu.a',
needed by `/home/cjia/scratch/workareas/vtd/xen-unstable-latest.hg/stubdom/mini-os-x86_64-ioemu/mini-os_app.o'.
 Stop.

Thanks,
Neo
-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!

stubdom build failure

[George Dunlap]

When I try to compile stubdoms, I get the following build failure:

ld -nostdlib -L/xensource/hg/open-source/xen-unstable.hg/stubdom/cross-root-i686/i686-xen-elf/lib
 -m elf_i386 -T arch/x86/minios-x86_32.lds
/xensource/hg/open-source/xen-unstable.hg/stubdom/mini-os-x86_32-ioemu/mini-os.o
 -o /xensource/hg/open-source/xen-unstable.hg/stubdom/mini-os-x86_32-ioemu/mini-os
/xensource/hg/open-source/xen-unstable.hg/stubdom/mini-os-x86_32-ioemu/mini-os.o:
In function `xenstore_dom_chmod':
/xensource/hg/open-source/xen-unstable.hg/stubdom/ioemu/xenstore.c:1531:
undefined reference to `xs_strings_to_perms'
/xensource/hg/open-source/xen-unstable.hg/stubdom/ioemu/xenstore.c:1532:
undefined reference to `xs_set_permissions'
make[2]: *** [/xensource/hg/open-source/xen-unstable.hg/stubdom/mini-os-x86_32-ioemu/mini-os]
Error 1
make[2]: Leaving directory
`/xensource/hg/open-source/xen-unstable.hg/extras/mini-os'
make[1]: *** [ioemu-stubdom] Error 2
make[1]: Leaving directory `/xensource/hg/open-source/xen-unstable.hg/stubdom'
make: *** [install-stubdom] Error 2


If I do a recursive grep, I can see xs_strings_to_perms() in libxc, so
I'm not sure what the problem is...

 -George

Re: stubdom build failure

[Stefano Stabellini]

On Wed, 29 Jul 2009, George Dunlap wrote:
> When I try to compile stubdoms, I get the following build failure:
> 
> ld -nostdlib -L/xensource/hg/open-source/xen-unstable.hg/stubdom/cross-root-i686/i686-xen-elf/lib
>  -m elf_i386 -T arch/x86/minios-x86_32.lds
> /xensource/hg/open-source/xen-unstable.hg/stubdom/mini-os-x86_32-ioemu/mini-os.o
>  -o /xensource/hg/open-source/xen-unstable.hg/stubdom/mini-os-x86_32-ioemu/mini-os
> /xensource/hg/open-source/xen-unstable.hg/stubdom/mini-os-x86_32-ioemu/mini-os.o:
> In function `xenstore_dom_chmod':
> /xensource/hg/open-source/xen-unstable.hg/stubdom/ioemu/xenstore.c:1531:
> undefined reference to `xs_strings_to_perms'
> /xensource/hg/open-source/xen-unstable.hg/stubdom/ioemu/xenstore.c:1532:
> undefined reference to `xs_set_permissions'
> make[2]: *** [/xensource/hg/open-source/xen-unstable.hg/stubdom/mini-os-x86_32-ioemu/mini-os]
> Error 1
> make[2]: Leaving directory
> `/xensource/hg/open-source/xen-unstable.hg/extras/mini-os'
> make[1]: *** [ioemu-stubdom] Error 2
> make[1]: Leaving directory `/xensource/hg/open-source/xen-unstable.hg/stubdom'
> make: *** [install-stubdom] Error 2
> 
> 
> If I do a recursive grep, I can see xs_strings_to_perms() in libxc, so
> I'm not sure what the problem is...

That is a known issue I haven't had the time to fix yet.
But you just need to downgrade qemu before

ad202d4194eab87d3645f13e7726a4d609e42fe8

Re: stubdom build failure

[Keir Fraser]

On 29/07/2009 15:37, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> If I do a recursive grep, I can see xs_strings_to_perms() in libxc, so
> I'm not sure what the problem is...

Probably undefined for xc_minios.c. I fixed this by reverting QEMU_TAG in
xen-unstable's Config.mk. So you still have the old tag, or somesuch.

 -- Keir