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 12:12:54 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 28 Apr 2009 03:13:26 -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:

> Have you, like in the C example of stubdom/Makefile, propagated
> TARGET_CPPFLAGS, TARGET_CFLAGS, and added a rule like is done for other
> stubdom images in the "minios" paragraph of stubdom/Makefile?

No, I had no idea how to start with this, I stole the various flags
from the output of make c-stubdom and configured ncurses with those.

> 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.

Oh yes, I copied that, but forgot the install step, because the build
itself was so tedious.

> Ferenc Wagner, le Mon 27 Apr 2009 22:29:02 +0200, a .ANicrit :
>> I couldn't track how it's done for libpci & libz for qemu-stubdom
>> (ioemu?) yet.
> It's all in stubdom/Makefile: they get installed within the
> cross-root-$(GNU_TARGET_ARCH) hierarchy, where the linker finds it
> thanks to the TARGET_LDFLAGS variable.
>> This make magic is somewhat convoluted,
> It's no magic, it's makefiles :)

Ok, do I have to extend the # Links section as well?

>> So, where should I add it for proper operation?
> Just the same way as zlib & C stubdom examples.

I may be blind, but there's no -l linker option in stubdom/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.

Thanks for the tip.

>> /home/wferi/xen/grub2/util/getroot.c:215: undefined reference to `lstat'
>> /home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tty/lib_tstp.c:159:
>>  undefined reference to `tcgetpgrp'
>> /home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tty/lib_tstp.c:159:
>>  undefined reference to `getpgrp'
>> /home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:143:
>>  undefined reference to `tcflush'
> Should be fixed by the patch below.

And thanks for the patch!  Will try once I get a correct build

>> /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!

Yeah, I copied those defines from my libc headers.  Figured I won't
need them after all, as the MiniOS console won't care, so I can stub
them out later.  But wanted a proof of concept first of all.

>> /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.

Hmm, I don't remember hacking around this...

>> /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.

Thanks, that's about what I expected.  Will do.

Until then, here are my notes from the yesterday session.  If you have
further comments, I'd be glad to hear them.



1. wferi@rs22:~/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses$ gcc 
-DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include  -DNDEBUG 
 -isystem /home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include 
-D__MINIOS__ -DHAVE_LIBC -isystem 
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/posix -isystem 
/home/wferi/xen/xen-3.3.1/stubdom/../tools/xenstore  -isystem 
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/x86 -isystem 
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/x86/x86_32 -U 
__linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem 
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/posix -isystem 
/home/wferi/xen/xen-3.3.1/stubdom/cross-root-i686/i686-xen-elf/include -isystem 
/usr/lib/gcc/i486-linux-gnu/4.3.2/include -isystem 
/home/wferi/xen/xen-3.3.1/stubdom/lwip-x86_32/src/include -isystem 
/home/wferi/xen/xen-3.3.1/stubdom/lwip-x86_32/src/include/ipv4 -I/ho
 me/wferi/xen/xen-3.3.1/stubdom/include  -O1 -fno-omit-frame-pointer 
-fno-optimize-sibling-calls  -m32 -march=i686 -m32 -march=i686 -g 
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value 
-Wdeclaration-after-statement   -fno-stack-protector   --param 
max-inline-insns-single=1200 -c ../objects/tty_update.c -o 

That is, both lwip -isystem pathes missed the -x86_32 bit (the original was the 
of adapting the zlib cross-compilation stanza in stubdom/Makefile:



# Cross-ncurses

        $(WGET) $(NCURSES_URL)/$@

ncurses-$(XEN_TARGET_ARCH): ncurses-$(NCURSES_VERSION).tar.gz
        tar xzf $<
        mv ncurses-$(NCURSES_VERSION) $@

.PHONY: cross-ncurses
cross-ncurses: $(NCURSES_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 

1b. Fix the two include pathes in stubdom/Makefile:

TARGET_CPPFLAGS += -isystem $(CURDIR)/lwip-x86_32/src/include
TARGET_CPPFLAGS += -isystem $(CURDIR)/lwip-x86_32/src/include/ipv4

(Probably helps after reconfiguration only.)

2. Some other file required renaming the local variable holding the current
screen from 'current' to 'currrent' (cca. 3 occurences) due to some strange
Xen include clash?!

3. 'columns' in the above tty_update.c has a similar problem.  Moving
#include <curses.priv.h> past #include <sys/select.h> solves this, but still 
../ncurses/./tty/tty_update.c:351: warning: implicit declaration of function 

4. Add to ../ncurses/./tinfo/lib_baudrate.c, above 'static struct speed const 
speeds[] =':

/* Copied from Linux' /usr/include/bits/termios.h, Mini-OS has no support for 
these */
#define  B0     0000000         /* hang up */
#define  B50    0000001
#define  B75    0000002
#define  B110   0000003
#define  B134   0000004
#define  B150   0000005
#define  B200   0000006
#define  B300   0000007
#define  B600   0000010
#define  B1200  0000011
#define  B1800  0000012
#define  B2400  0000013
#define  B4800  0000014
#define  B9600  0000015
#define  B19200 0000016
#define  B38400 0000017

5. Add to the head of ../ncurses/./tinfo/lib_kernel.c:

/* Copied from Linux' /usr/include/bits/termios.h, Mini-OS has no support for 
these */
#define VERASE 2
#define VKILL 3
#define TCIFLUSH        0

Maybe #undef TERMIOS would be better?  This still leaves:
../ncurses/./tinfo/lib_kernel.c:143: warning: implicit declaration of function 

6. #include <curses.priv.h> problem in ../ncurses/./tty/lib_twait.c, too.

7. These alone get us a libncurses.a!

8. The 'form' part still does not compile, because the field 'current' in 
clashes with the #define current at
This is the same problem as 2., but without an easy fix, as this 'current' 
isn't a
local variable.

9. Actually, deleting #define current get_current() from 
made libncurses++.a build, but broke make c-stubdom...  According to Keir 
Fraser, the simplest fix is:

#ifdef __MINIOS__
#define current get_current()

Xen-devel mailing list

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