Allow for Cross compile of user tools
PATCH 1/1 Allow for Cross compile of user tools
This is the first of many patches to begin to make kvm source a lot better for compiling for other architecture support (that is not x86 or x86-64).
This patch makes it possible so that someone on an x86 machine can cross compile for an x86-64 machine and vice versa. So now you will have config-$(arch).mak for each architecture, with specific architecture rules.
An example of this is for compiling x86-64 on an x86 machine is:
make KERNELDIR=~/tmp/kvm ARCH=x86_64
This allows for someone with an x86 machine to compile for x86_64. Later patches that I will be submitting will be for ppc and will make a few more changes.
What I would like though is comments on how everyone feels about this approach. We are need of something like this to start ading ppc related code.
user/Makefile +14 -25
@@ -1,5 +1,12 @@ -include config.mak +ARCH ?= $(shell uname -m | sed -e s/i.86/x86/) + +KERNELDIR ?= /lib/modules/$(shell uname -r)/build/ + +DESTDIR ?= + +#include architecure specific make rules +include config-$(ARCH).mak # cc-option # Usage: OP_CFLAGS+=$(call cc-option, -falign-functions=0, -malign-functions=0)
@@ -7,8 +14,8 @@ include config.mak cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null \ > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;) -CFLAGS = -I $(KERNELDIR)/include $(autodepend-flags) -g -fomit-frame-pointer \ - -Wall -m$(bits) +CFLAGS += -I $(KERNELDIR)/include $(autodepend-flags) -g -fomit-frame-pointer \ + -Wall CFLAGS += $(call cc-option, -fno-stack-protector, "") CFLAGS += $(call cc-option, -fno-stack-protector-all, "")
@@ -18,20 +25,6 @@ CXXFLAGS = $(autodepend-flags) autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d -DESTDIR = - -ifeq ($(shell uname -m), x86_64) -LIBDIR = /lib64 -cstart.o = test/cstart64.o -bits = 64 -ldarch = elf64-x86-64 -else -LIBDIR = /lib -cstart.o = test/cstart.o -bits = 32 -ldarch = elf32-i386 -endif - all: kvmctl libkvm.a flatfiles kvmctl: LDFLAGS += -pthread -lrt
@@ -45,11 +38,7 @@ libkvm.a: kvmctl.o flatfiles-common = test/bootstrap test/vmexit.flat test/smp.flat -flatfiles-32 = - -flatfiles-64 = test/access.flat test/irq.flat test/sieve.flat test/simple.flat test/stringio.flat test/memtest1.flat - -flatfiles: $(flatfiles-common) $(flatfiles-$(bits)) +flatfiles: $(flatfiles-common) $(flatfiles) install: install -D kvmctl.h $(DESTDIR)/$(PREFIX)/include/kvmctl.h
@@ -60,13 +49,13 @@ install: install -D libkvm.a $(DESTDIR)/$(PREFIX)/$(LIBDIR)/libkvm.a %.flat: %.o - gcc $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $^ + $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $^ test/bootstrap: test/bootstrap.o - gcc -nostdlib -o $@ -Wl,-T,bootstrap.lds $^ + $(CC) -nostdlib -o $@ -Wl,-T,bootstrap.lds $^ %.o: %.S - gcc $(CFLAGS) -c -nostdlib -o $@ $^ + $(CC) $(CFLAGS) -c -nostdlib -o $@ $^ test/irq.flat: test/print.o
user/config-x86.mak new file +7 -0
@@ -0,0 +1,7 @@ +LIBDIR = /lib +cstart.o = test/cstart.o +bits = 32 +ldarch = elf32-i386 +CFLAGS += -m32 + +flatfiles=
user/config-x86_64.mak new file +7 -0
@@ -0,0 +1,7 @@ +LIBDIR = /lib64 +cstart.o = test/cstart64.o +bits = 64 +ldarch = elf64-x86-64 +CFLAGS += -m64 + +flatfiles = test/access.flat test/irq.flat test/sieve.flat test/simple.flat test/stringio.flat test/memtest1.flat
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Quoted 4 lines · Jerone Young
This is the first of many patches to begin to make kvm source a lot better for compiling for other architecture support (that is not x86 or x86-64).
Quoted 8 lines
This patch makes it possible so that someone on an x86 machine can cross compile for an x86-64 machine and vice versa. So now you will have config-$(arch).mak for each architecture, with specific architecture rules.
An example of this is for compiling x86-64 on an x86 machine is:
make KERNELDIR=~/tmp/kvm ARCH=x86_64
This should be done via ./configure (I dislike ?= intensely).
Quoted 9 lines
This allows for someone with an x86 machine to compile for
x86_64. Later patches that I will be submitting will be for ppc and will make a few more changes.What I would like though is comments on how everyone feels about this approach. We are need of something like this to start ading ppc related code.
No problem for user/. I'd like to see this accepted by qemu-devel as well.
Signature · 7 lines
Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): 4701DE24.4030109-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 10 lines · Avi Kivity
Quoted 9 lines · Jerone Young
This is the first of many patches to begin to make kvm source a lot better for compiling for other architecture support (that is not x86 or x86-64).
This patch makes it possible so that someone on an x86 machine can cross compile for an x86-64 machine and vice versa. So now you will have config-$(arch).mak for each architecture, with specific architecture rules.
Quoted 5 lines
Quoted 3 lines
An example of this is for compiling x86-64 on an x86 machine is:
make KERNELDIR=~/tmp/kvm ARCH=x86_64This should be done via ./configure (I dislike ?= intensely).
This is something that could be done via the ./configure script. What will need to add is ARCH=, CC=, LD= as variables as well.
I can create a patch for this.
Quoted 5 lines
Quoted 5 lines
This allows for someone with an x86 machine to compile for
x86_64. Later patches that I will be submitting will be for ppc and will make a few more changes.
Quoted 7 lines
Quoted 5 lines
What I would like though is comments on how everyone feels about this approach. We are need of something like this to start ading ppc related code.
No problem for user/. I'd like to see this accepted by qemu-devel as well.
Well qemu pretty much has this problem taken care of. In qemu you can just use the autoconf system. So for our purposes with PPC development we need to compile the binaries on an x86 machine (as the embedded boards are of course much slower, then our super x86 machines). So you just launch configure in qemu with the options:
./configure \ --cpu=powerpc \ --cross-prefix=powerpc-440-linux-gnu-
This will compile qemu for the target CPU powerpc and will use cross compile tools with prefix "powerpc-440-linux-gnu-" that are in our PATH. So we have for example powerpc-440-linux-gnu-gcc which is used to compile the proper ppc binary.
All in all these patches whouldn't be needed in qemu because it already has this problem taken care of. But the test case directory /user do not have this problem taken care of. It assumes that you will run on the machine that you are compiling on.
Quoted 1 line
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/