Just got this email, after sending the access.c fix. On Sat, 2008-07-05 at 20:36 +0300, Avi Kivity wrote: > Jerone Young wrote: > > On Sat, 2008-07-05 at 12:28 +0300, Avi Kivity wrote: > > > >> Jerone Young wrote: > >> > >>> On Sun, 2008-06-29 at 16:24 +0300, Avi Kivity wrote: > >>> > >>> > >>>> Avi Kivity wrote: > >>>> > >>>> > >>>>> Jerone Young wrote: > >>>>> > >>>>> > >>>>>> This set of patches are to consolidate test libraries into a single > >>>>>> library archive. This lib archive is libcflat. This will allow common > >>>>>> code to be shared among archs. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> Applied all, thanks. I squashed together 1-3 as Hollis suggested, and > >>>>> with git's rename detection, one can see that you merged exit() puts() > >>>>> etc into a single file. That usually doesn't work will with libraries > >>>>> (if you define your own puts() but not your own exit(), you're in > >>>>> trouble), but we can fix this if/when it starts to hurt. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> This fails compilation with: > >>>> > >>>> gcc -m64 -D__x86_64__ -I /tmp/BUILDER/kvm/rpmtop/BUILD/kernel/include > >>>> -O1 -MMD -MF test/x86/.access.d -g -fomit-frame-pointer -Wa > >>>> ll -fno-stack-protector -I ../libkvm -std=gnu99 -ffreestanding -I > >>>> test/lib -I test/lib/x86 -c -o test/x86/access.o test/x86/a > >>>> ccess.c > >>>> test/x86/access.c:153: error: conflicting types for 'memset' > >>>> /usr/include/string.h:59: error: previous declaration of 'memset' was here > >>>> test/x86/access.c: In function 'ac_test_do_access': > >>>> test/x86/access.c:511: warning: implicit declaration of function 'printf' > >>>> test/x86/access.c: In function 'main': > >>>> test/x86/access.c:578: warning: passing argument 1 of 'smp_init' from > >>>> incompatible pointer type > >>>> make[1]: *** [test/x86/access.o] Error 1 > >>>> make[1]: Leaving directory `/tmp/BUILDER/kvm/rpmtop/BUILD/user' > >>>> error: Bad exit status from /var/tmp/rpm-tmp.45450 (%build) > >>>> > >>>> So I'm unapplying these patches. > >>>> > >>>> > >>>> > >>> Ah. Sorry about that. I was testing on x86 and not x86-64. So I didn't > >>> notice that config-x86_64.mak had other test cases outside of what was > >>> in config-x86-common. > >>> > >>> The problem here is access.c needs to include the new libcflat.h , and > >>> not printf.h . In one of my patches. > >>> > >>> Since I don't currently have an x86-64 setup to try, can't turn out a > >>> patch. I can give you an idea of what is up so here are the changes > >>> needed for test/x86/access.c: > >>> > >>> jerone@thinkpadL:~/work/kvm-userspace/user/test/x86$ vi access.c.FIXED > >>> jerone@thinkpadL:~/work/kvm-userspace/user/test/x86$ diff -aurp access.c access.c.FIXED > >>> --- access.c 2008-06-09 08:57:25.000000000 -0500 > >>> +++ access.c.FIXED 2008-07-01 02:32:41.000000000 -0500 > >>> @@ -1,7 +1,6 @@ > >>> > >>> -#include "smp.h" > >>> -#include "printf.h" > >>> -#include "string.h" > >>> +#include <x86/smp.h> > >>> +#include <libcflat.h> > >>> > >>> > >>> > >> Er, <> includes are for system headers. Please stick to "" includes. > >> The previous patches also need to be fixed. > >> > > > > Actually the include paths to not use system includes. Ok can do this. Will fix up all the test files to use "" instead of <>. > > > > > > <> means system include file. libcflat.h is not a system include file, > so no pointy brackets. > > > Just setup an x86-64 compilation enviroment. Looks like access.c was the > > only test that had the problem. Also the pseudo patch I sent ended up > > being the solution. I will send a formal patch set shortly so you can > > include libcflat. > > > > Thanks. Please don't send separate create and delete patches, and use > diff -M, so that we see exactly what's changed rather than a zillion and > a half adds and removes. I'll see what I can do. Though I depend on hg to generate the patches. So I'll see if I can have just have remove for files (but no promises). I'll just merge everything into one big patch. > > -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
