This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: Pesky '#define current' in mini-os/sched.h

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: Pesky '#define current' in mini-os/sched.h
From: Ferenc Wagner <wferi@xxxxxxx>
Date: Tue, 28 Apr 2009 19:57:07 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 28 Apr 2009 10:59:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090427211132.GR5965@xxxxxxxxxxxxxxxxxxxxxxxxx> (Samuel Thibault's message of "Mon, 27 Apr 2009 23:11:32 +0200")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87k5563r1v.fsf@xxxxxxxxxxxxx> <20090427182543.GD5965@xxxxxxxxxxxxxxxxxxxxxxxxx> <877i163pga.fsf@xxxxxxxxxxxxx> <20090427185955.GF5965@xxxxxxxxxxxxxxxxxxxxxxxxx> <873abt51e5.fsf@xxxxxxxxxxxxx> <20090427200544.GN5965@xxxxxxxxxxxxxxxxxxxxxxxxx> <87skjt3koh.fsf@xxxxxxxxxxxxx> <20090427211132.GR5965@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> writes:

> Ferenc Wagner, le Mon 27 Apr 2009 22:29:02 +0200, a écrit :
>> LDLIBS := -L/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/lib -lncurses
> That's not how it's supposed to be done. See the Cross-zlib paragraph
> for instance: the cross-zlib target not only configures & builds libz,
> but also installs it, the prefix being properly set during configuration
> into the cross-chain directory.

Now I have ncurses installed into cross-root.  Suppose I want to use
it from c-stubdom.  #include <ncurses/curses.h> works without any
further modification, but where should I put -lncurses?  The best I
could come up with is APP_LDLIBS in extras/mini-os/Makefile...

>> /home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function 
>> `grub_memalign':
>> /home/wferi/xen/grub2/util/misc.c:263: undefined reference to 
>> `posix_memalign'
> It should just be a matter of setting it as an alias for newlib's
> memalign, by adding a macro into newlib/libc/include/malloc.h for
> instance.  Ideally it should be reported to newlib's upstream actually.

Seems good.

> Should be fixed by the patch below.

Works as advertised, thanks!

>> /home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_baudrate.c:244:
>>  undefined reference to `cfgetospeed'
> I'm a bit surprised you actually got code using cfgetospeed compiled in
> the miniOS environment.  It's supposed to return something like B9600,
> but that's not defined by newlib!

I'll stub this to always return B38400 and define those constants.  Do
you think it matters the least?

>> /home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:67:
>>  undefined reference to `fpathconf'
> Same issue: how did you get that code to compile? _PC_VDISABLE is not
> defined...  I believe you are not using the cross-chain flags.

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?

>> /home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:112:
>>  undefined reference to `access'
>> /home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:125:
>>  undefined reference to `access'
> Mmmm, the fsif protocol does not provide an access operation to
> implement that properly. You could add a dummy implementation in
> lib/sys.c that just open()/close() it and return proper error codes if
> any and it should be fine for ncurses' use cases.

I stubbed this last one, and now I can compile the ncurses example at
http://www.captain.at/howto-curses-example.php as a c-stubdom; too bad
it does not work:

Error opening terminal: unknown.

Now let's try to hardwire the terminal type to xterm or similar...

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>