Hi Samuel,
I've just sent the summary mail before reading yours...
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 mean by "stubbing"? An implementation just always
> returning an error?
Or rather success, in this case. But yes.
>> 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.
> 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. That may or may not work out. All I know is
http://grub.enbug.org/FranklinPiat/grub-emu.manpage
Failure was and is an option. :)
>> Ok, do I have to extend the # Links section as well?
>
> You need to add a cross-ncurses dependency, but the rest is only for
> libxc.
I wonder how I got it right...
>> 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. Looks like I
really had better starting with the development tree, but I read
stubdom has problems there...
>> 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.
> I'm actually feared by all your terminal additions. These will probably
> never be implemented in mini-os. They can sure be stubbed, but the
> application will probably just not work properly. Remember that the Xen
> console can be attached/detached/reattached from a lot of various kinds
> of terminals...
Yes, the terminal type should be propagated (and changed on the fly)
in mini-os, which is infeasible. Either one has to stick to some
common subset or use this in short-lived stub domains only. For
example with a boot loader. :)
>> 9. Actually, deleting #define current get_current() from
>> extras/mini-os/include/mini-os/sched.h made libncurses++.a build,
>> but broke make c-stubdom... According to Keir Fraser, the simplest
>> fix is:
>>
>> #ifdef __MINIOS__
>> #define current get_current()
>> #endif
>
> Use the same fix as in the unstable tree.
Yes, it didn't work, __MINIOS__ is defined all the time. I worked
around in ncurses instead for now.
So let's see how grub-emu likes this environment...
--
Thanks,
Feri.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home