Ferenc Wagner, le Tue 28 Apr 2009 20:47:41 +0200, a écrit :
> Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> writes:
> > Ferenc Wagner, le Tue 28 Apr 2009 19:57:07 +0200, a écrit :
> >> newlib-1.16.0/newlib/libc/include/sys/unistd.h defines _PC_VDISABLE.
> >> It even has an fpathconf implementation in libc/sys/linux. Is there a
> >> way to get that work or had I better stub this one, too?
> >
> > Oh, right it's not defined in the linux/ part.
> > That one should be fine indeed.
>
> Do you know offhand why it isn't found?
What do you refer to by "it"?
_PC_VDISABLE is in the generic part, so that's why ncurses sees it.
fpathconf is in the linux/ part, so that's why it's not compiled in.
Just take that implementation and it will get compiled in.
> >> Now let's try to hardwire the terminal type to xterm or similar...
> >
> > Note that for that to eventually work you need to give your stubdomain
> > access to the terminfo database via fsif.
>
> For now I configured out database access and compiled in some fallbacks.
Ok, that should be fine. In that case, maybe you should rather stub
access() as always failing, as it's not supposed to read files.
> > Now, I'm wondering about the ncurses requirement: is grub2 really
> > using it for the bootloader, not just for the userland tool?
>
> No, it does not require it for the bootloader. My plan is to port the
> grub-emu userland tool instead, and finally patch kexec on that, just
> like you did with grub1.
Err, I didn't port the userland tool, I ported the bootloader. The
userland grub1 tool does not even include code to boot kernels,
actually...
> >> I may be blind, but there's no -l linker option in stubdom/Makefile.
> >
> > Sure, but in qemu/ there is a -lz linker option. Just the usual way,
> > that is.
>
> There's no qemu/ in the 3.3.1 tree, as far as I can see.
It's a symlink to the ioemu/ tree, yes, I didn't mean a precise
directory name, just vaguely evoking ioemu.
> >> NCURSES_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libncurses.a
> >> .PHONY: cross-ncurses
> >> cross-ncurses: $(NCURSES_STAMPFILE)
> >> $(NCURSES_STAMPFILE): ncurses-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE)
> >> ( cd $< && \
> >> CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" CC=$(CC)
> >> ./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf
> >> --with-build-cppflags="" --with-build-cflags="" --with-build-ldflags=""
> >> --with-build-libs="" && \
> >> $(MAKE) libs && \
> >> $(MAKE) install.libs )
> >>
> >> The --with-build-* options do nothing, so two utilities must be compiled
> >> by hand.
> >
> > You need to pass the $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) there.
>
> Sorry, I don't understand. Where? The target flags are the very
> thing causing the problem for the build helper programs.
In --with-build-*, I guess. What do you hope to build with helper
programs? Mini-OS kernels? That would indeed require much more
invasive Makefile changes in ncurses. I don't think you need that
anyway.
Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home