Re: [User-mode-linux-devel] Cannot compile uml-2.3.99-pre2 from sources

[Jeff D. <jd...@ka...>]

> I tried to build uml-2.3.99-pre2 from sources, but failed. 

I just grabbed my patch from sourceforge and rebuilt a kernel, so it's not 
hopelessly bad :-)

> moreover CVS and patch give different source trees. 

This surprises me a little, but not too much.  My CVS discipline has not been 
the best in the past, although I added something to the -pre2 build which 
should have caught any lingering differences.  I'll check this out and make 
CVS match the patch.

>     - um/kernel/irq.c references "linux/tasks.h" which does not
> exists; 

This is true.  I'll see if there's an easy way to prevent the compiler from 
looking in /usr/include (nostdinc does, but when I looked at that before, I 
thought there were nasty side-effects which couldn't be avoided).

You can get rid of that include.

>     - many files (for example syscall_user.c) include both "asm/
> somefile.h" and "somefile.h"
>       which have conflicts (/usr/include/unistd.h from glibc 2.1.3 and
> asm/unistd.h); 

This is ok.  It should get /usr/include/asm/somefile.h and 
/usr/include/somefile.h.  It should not get $(TOPDIR)/include/asm/somefile.h. 
and this is guaranteed by stripping that -I from the command line.  This is 
the compile line for syscall_user.c:
	gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ 
-D__arch_um__ -fwritable-strings -fno-strict-aliasing -I../include  -c -o 
syscall_user.o syscall_user.c

The compiler has no way of finding the kernel headers.  It gets system headers 
and what's in ../include.

> The question is: where may I find good uml sources?

The patch is as good as you're going to get from me :-)

In order to fix this, I need to see your build output.

If you want to look into this yourself, the thing you need to know is this:
	The uml sources are divided into user-space files, which include only system 
headers and no kernel headers, and kernel files, which include only kernel 
headers and no system headers.  They communicate through headers that they 
both include, which are mostly located in arch/um/include (and a couple in 
arch/um/drivers).

Compile problems happen when system headers sneak into kernel files or kernel 
headers sneak into user-space files.  I've seen cases where I have a header 
missing from include/asm and the compiler finds the file in /usr/include/asm 
instead (and I'll check to see if -nostdinc will prevent that).  The rewriting 
of CFLAGS to eliminate the -I$(TOPDIR)/include from user-space file compiles 
should prevent kernel headers from sneaking into them.

				Jeff