Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> writes:
> 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"?
The fpathconf implementation.
> _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.
Ah, I wasn't aware of this distinction.
> Just take that implementation and it will get compiled in.
Sorry for sounding dense... How do I "take that implementation"? I
guess you don't mean cut&paste, do you?
>> 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.
Not for the ncurses library, but maybe for something else...
>>> 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...
Yes, it's all the same for grub2. With "just like you did" I meant
patching in kexec, so that the grub-emu userland tool can actually
boot kernels. You also needed to patch kexec onto the grub1 boot
loader (but not the userland tool).
>>>> 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.
OK, in ioemu I found
tapdisk-ioemu: tapdisk-ioemu.c cutils.c block.c block-raw.c block-cow.c
block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c
block-vpc.c block-vvfat.c block-qcow2.c hw/xen_blktap.c osdep.c
$(CC) -DQEMU_TOOL $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) $(LDFLAGS)
$(BASE_LDFLAGS) -o $@ $^ -lz $(LIBS)
and
qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c block-cow.c
block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c
block-vpc.c block-vvfat.c block-qcow2.c
$(CC) -DQEMU_TOOL $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) $(LDFLAGS)
$(BASE_LDFLAGS) -o $@ $^ -lz $(LIBS)
but neither is applicable to c-stubdom, where the Makefile stops at
creating an archive. I can't add -lncurses there... And generally I
feel like being on a totally wrong track, as this part doesn't seem to
involve minios at all.
>>>> $(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.
Oh no, these helpers are run as part of the cross building process
itself, on the host system, not on the target. In the end I found a
way to override the target flags for them by specifying
BUILD_CCFLAGS="" as a make argument.
--
Feri.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home