Fix IA64 build with separate source and build trees.

Hi David,
This patch against 2.6.0-test7 fixes building in a separate output
directory. Without it, offsets.h isn't built, and the check-gas and toolchain-flags sscripts aren't found.

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas:
# ChangeSet v2.6.0-test7 -> 1.1512
# arch/ia64/Makefile 1.60 -> 1.62
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/10/08 [email protected] 1.1510
# Linux 2.6.0-test7
# --------------------------------------------
# 03/10/09 [email protected] 1.1511
# Fix IA64 build with separate source and build trees.
# --------------------------------------------
# 03/10/09 [email protected] 1.1512
# [IA64] arch/ia64/Makefile: Fix as per Sam Ravnborg's request: use $(srctree) not $(src) # --------------------------------------------
#

diff -Nru a/arch/ia64/Makefile b/arch/ia64/Makefile
@@ -25,9 +25,9 @@
 GCC_VERSION=$(shell $(CC) -v 2>&1 | fgrep 'gcc version' | cut -f3 -d' ' | cut -f1 -d'.')
 GCC_MINOR_VERSION=$(shell $(CC) -v 2>&1 | fgrep 'gcc version' | cut -f3 -d' ' | cut -f2 -d'.')
 
-GAS_STATUS=$(shell arch/ia64/scripts/check-gas $(CC) $(OBJDUMP))
+GAS_STATUS=$(shell $(srctree)/arch/ia64/scripts/check-gas $(CC) $(OBJDUMP))
 
-CPPFLAGS	+= $(shell arch/ia64/scripts/toolchain-flags $(CC) $(OBJDUMP))
+CPPFLAGS	+= $(shell $(srctree)/arch/ia64/scripts/toolchain-flags $(CC) $(OBJDUMP))
 
 ifeq ($(GAS_STATUS),buggy)
 $(error Sorry, you need a newer version of the assember, one that is built from	\

@@ -84,18 +84,21 @@
 archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)
 
-CLEAN_FILES += include/asm-ia64/.offsets.h.stamp include/asm-ia64/offsets.h vmlinux.gz bootloader
+CLEAN_FILES += include/asm-$(ARCH)/.offsets.h.stamp include/asm-$(ARCH)/offsets.h vmlinux.gz bootloader
 
-prepare: include/asm-ia64/offsets.h
+prepare: include/asm-$(ARCH)/offsets.h
+
+arch/$(ARCH)/kernel/asm-offsets.s: include/asm include/linux/version.h
 
 include/asm-$(ARCH)/offsets.h: arch/$(ARCH)/kernel/asm-offsets.s
 	$(call filechk,gen-asm-offsets)
 
-arch/ia64/kernel/asm-offsets.s: include/asm-ia64/.offsets.h.stamp
+arch/ia64/kernel/asm-offsets.s: include/asm-$(ARCH)/.offsets.h.stamp
 
-include/asm-ia64/.offsets.h.stamp:
-	[ -s include/asm-ia64/offsets.h ] \
-	 || echo "#define IA64_TASK_SIZE 0" > include/asm-ia64/offsets.h
+include/asm-$(ARCH)/.offsets.h.stamp:
+	mkdir -p include/asm-$(ARCH)
+	[ -s include/asm-$(ARCH)/offsets.h ] \
+	 || echo "#define IA64_TASK_SIZE 0" > include/asm-$(ARCH)/offsets.h
 	touch $@
 
 boot:	lib/lib.a vmlinux

I'm more curious than anything ...

[...]

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Matthew> I'm more curious than anything ...

Matthew> [...]

Matthew> What's the advantage to using $(ARCH) here? Since this is in Matthew> an arch directory, we already know our $ARCH. And if we are Matthew> going to use it, shouldn't it be used everywhere?

Main advantage is it makes this bit of code almost identical between architectures, so that when someone updates it a simple grep will find it everywhere. And yes, it should be ${ARCH} everywhere htat there's identical code between architectures (which means everywhere, for simplicity as to know when to use what)

Peter C

Peter> Main advantage is it makes this bit of code almost identical Peter> between architectures, so that when someone updates it a Peter> simple grep will find it everywhere. And yes, it should be Peter> ${ARCH} everywhere htat there's identical code between Peter> architectures (which means everywhere, for simplicity as to Peter> know when to use what)

I think we're going in circles. Originally, I had $(ARCH) for similar reasons as you state and then they got replaced by ia64 in the big Makefile rewrite. I don't really care much one way or the other, but let's be consistent. AFAIK, currently everybody is using the architecture name, so we probably should stick to that.

	--david