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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 existIt 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 includeIt looks like $(GCC_INSTALL) is empty, that''s your issue. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 hereThat''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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel