cleaning up "make headers_install" for various architectures

cleaning up "make headers_install" for various architectures

[Robert P. J. Day]

  there are a number of architectures that generate warnings (and, in
one case, an error) if you try to do:

  $ make ARCH=whatever headers_install

when you don't have an appropriate cross-compiler installed.  this
doesn't seem to make sense as you shouldn't have to do any actual
cross-compiling if you're just trying to install headers, should you?

  the examples (i already mentioned the ia64 example on that list):


$ make ARCH=m68k headers_install
make: m68k-linux-gnu-gcc: Command not found
  CHK     include/linux/version.h
  HOSTCC  scripts/unifdef
  MKDIR   include
  ... etc etc ...


$ make ARCH=h8300 headers_install
make: h8300-elf-gcc: Command not found
make: h8300-elf-gcc: Command not found
  CHK     include/linux/version.h
make[1]: `scripts/unifdef' is up to date.
  UNIFDEF include/asm/page.h
  ... etc etc ...


$ make ARCH=sparc64 headers_install
/bin/sh: sparc64-linux-gcc: command not found
make: sparc64-linux-gcc: Command not found
  CHK     include/linux/version.h
make[1]: `scripts/unifdef' is up to date.
  MKDIR   include/asm-sparc64
  ... etc etc ...


$ make ARCH=ia64 headers_install
/home/rpjday/k/git/arch/ia64/scripts/check-segrel.S: Assembler messages:
/home/rpjday/k/git/arch/ia64/scripts/check-segrel.S:1: Error: unknown pseudo-op: `.rodata'
/home/rpjday/k/git/arch/ia64/scripts/check-segrel.S:2: Error: no such instruction: `data4 @segrel(start)'
objdump: '/tmp/out3703': No such file/home/rpjday/k/git/arch/ia64/scripts/toolchain-flags: line 19: [: !=:
unary operator expected


  the final example, parisc, just plain fails:

$ make ARCH=parisc headers_install
/home/rpjday/k/git/scripts/gcc-version.sh: line 16: hppa-linux-gcc: command not found
/home/rpjday/k/git/scripts/gcc-version.sh: line 17: hppa-linux-gcc: command not found
/home/rpjday/k/git/arch/parisc/Makefile:39: *** Sorry, GCC v3.3 or above is required..  Stop.


rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: cleaning up "make headers_install" for various architectures

[Randy Dunlap]

On Wed, 10 Oct 2007 12:44:58 -0400 (EDT) Robert P. J. Day wrote:

>   the final example, parisc, just plain fails:
> 
> $ make ARCH=parisc headers_install
> /home/rpjday/k/git/scripts/gcc-version.sh: line 16: hppa-linux-gcc: command not found
> /home/rpjday/k/git/scripts/gcc-version.sh: line 17: hppa-linux-gcc: command not found
> /home/rpjday/k/git/arch/parisc/Makefile:39: *** Sorry, GCC v3.3 or above is required..  Stop.


Try
$ make CROSS_COMPILE="" CC=gcc ARCH=parisc headers_install

:(
---
~Randy

Re: cleaning up "make headers_install" for various architectures

[Robert P. J. Day]

On Wed, 10 Oct 2007, Randy Dunlap wrote:

> On Wed, 10 Oct 2007 12:44:58 -0400 (EDT) Robert P. J. Day wrote:
>
> >   the final example, parisc, just plain fails:
> >
> > $ make ARCH=parisc headers_install
> > /home/rpjday/k/git/scripts/gcc-version.sh: line 16: hppa-linux-gcc: command not found
> > /home/rpjday/k/git/scripts/gcc-version.sh: line 17: hppa-linux-gcc: command not found
> > /home/rpjday/k/git/arch/parisc/Makefile:39: *** Sorry, GCC v3.3 or above is required..  Stop.
>
>
> Try
> $ make CROSS_COMPILE="" CC=gcc ARCH=parisc headers_install
>
> :(
> ---
> ~Randy

oh, i know how to get around it -- i was just thinking that it
shouldn't *require* a workaround, that's all.  all of those previous
warnings and errors are clearly due to the early part of the make
testing for the appropriate arch-specific build tools without
realizing that the make target doesn't *need* any of those things just
to install headers.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]

[Sam Ravnborg]

Added parisc mailing-listi and cc'ed parisc maintainers.

On Wed, Oct 10, 2007 at 01:26:16PM -0400, Robert P. J. Day wrote:
> On Wed, 10 Oct 2007, Randy Dunlap wrote:
> 
> > On Wed, 10 Oct 2007 12:44:58 -0400 (EDT) Robert P. J. Day wrote:
> >
> > >   the final example, parisc, just plain fails:
> > >
> > > $ make ARCH=parisc headers_install
> > > /home/rpjday/k/git/scripts/gcc-version.sh: line 16: hppa-linux-gcc: command not found
> > > /home/rpjday/k/git/scripts/gcc-version.sh: line 17: hppa-linux-gcc: command not found
> > > /home/rpjday/k/git/arch/parisc/Makefile:39: *** Sorry, GCC v3.3 or above is required..  Stop.
> >
> >
> > Try
> > $ make CROSS_COMPILE="" CC=gcc ARCH=parisc headers_install
> >
> > :(
> > ---
> > ~Randy
> 
> oh, i know how to get around it -- i was just thinking that it
> shouldn't *require* a workaround, that's all.  all of those previous
> warnings and errors are clearly due to the early part of the make
> testing for the appropriate arch-specific build tools without
> realizing that the make target doesn't *need* any of those things just
> to install headers.

parisc arch Makefile needs some love and care...

The logic selecting CROSS_COMPILE seems fishy and wrong -
the error reported by rday is obvious in this respect.

FINAL_LD is unused - kill it.

Building with oldpalo has been broken for a loong time - time to kill it?
Hint - the "cd ../palo" is not working as expected.
And use of TOPDIR is deprecated.

The libs-y assignment should learn from the other architectures how to
get the gcc lib filename:
$(shell $(CC) $(CFLAGS) -print-libgcc-file-name)


And this snippet is also wrong:
PALO := $(shell if which palo; then : ; \
	elif [ -x /sbin/palo ]; then echo /sbin/palo; \
	fi)

palo: vmlinux
	@if [ -x $PALO ]; then \


Make does not export variables so $PALO is not the same as $(PALO).
The latter should be used.

I did not supply a patch because I do not fully understand the
logic behind setting CROSS_COMPILE and 64BIT or not.
But I will be happy to review a patch to fix the issues in the
parisc Makefile.

	Sam

Re: parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]

[Kyle McMartin]

On Wed, Oct 10, 2007 at 08:38:58PM +0200, Sam Ravnborg wrote:
> parisc arch Makefile needs some love and care...
> 

It basically hasn't been touched since 2.4, I already have a patch to
clean up a lot of things when Randy pointed it out a while ago. Thanks
for the reminder, I'll queue it for 2.6.24.

Regards,
	Kyle

> The logic selecting CROSS_COMPILE seems fishy and wrong -
> the error reported by rday is obvious in this respect.
> 
> FINAL_LD is unused - kill it.
> 
> Building with oldpalo has been broken for a loong time - time to kill it?
> Hint - the "cd ../palo" is not working as expected.
> And use of TOPDIR is deprecated.
> 
> The libs-y assignment should learn from the other architectures how to
> get the gcc lib filename:
> $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> 
> 
> And this snippet is also wrong:
> PALO := $(shell if which palo; then : ; \
> 	elif [ -x /sbin/palo ]; then echo /sbin/palo; \
> 	fi)
> 
> palo: vmlinux
> 	@if [ -x $PALO ]; then \
> 
> 
> Make does not export variables so $PALO is not the same as $(PALO).
> The latter should be used.
> 
> I did not supply a patch because I do not fully understand the
> logic behind setting CROSS_COMPILE and 64BIT or not.
> But I will be happy to review a patch to fix the issues in the
> parisc Makefile.

I'll add this to the patch as well.

Re: parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]

[Sam Ravnborg]

On Wed, Oct 10, 2007 at 03:38:27PM -0400, Kyle McMartin wrote:
> On Wed, Oct 10, 2007 at 08:38:58PM +0200, Sam Ravnborg wrote:
> > parisc arch Makefile needs some love and care...
> > 
> 
> It basically hasn't been touched since 2.4,
Seems I did 25% of the changes since day 0 (counted from when
we started to use git for the kernel).

> I already have a patch to
> clean up a lot of things when Randy pointed it out a while ago. Thanks
> for the reminder, I'll queue it for 2.6.24.

Thanks -I assume you coordinate with Matthew.

	Sam

Re: parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]

[Matthew Wilcox]

On Wed, Oct 10, 2007 at 08:38:58PM +0200, Sam Ravnborg wrote:
> parisc arch Makefile needs some love and care...

None of your comments actually address the thing that he was having
problems with:

ifneq ($(call cc-ifversion, -lt, 0303, "bad"),)
$(error Sorry, GCC v3.3 or above is required.)
endif

Now, compiler.h has some checks like:

#elif __GNUC__ == 3 && __GNUC_MINOR__ >= 2
# include <linux/compiler-gcc3.h>
#else
# error Sorry, your compiler is too old/not recognized.
#endif

But it doesn't permit us to rule out gcc 3.3 unless we patch compiler.h.
There's no asm/compiler.h, for example.  Obviously, we could put some
tests for compiler version in arch/parisc somewhere.  Where's the right
place these days?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]

[Sam Ravnborg]

> 
> Now, compiler.h has some checks like:
> 
> #elif __GNUC__ == 3 && __GNUC_MINOR__ >= 2
> # include <linux/compiler-gcc3.h>
> #else
> # error Sorry, your compiler is too old/not recognized.
> #endif
> 
> But it doesn't permit us to rule out gcc 3.3 unless we patch compiler.h.
> There's no asm/compiler.h, for example.  Obviously, we could put some
> tests for compiler version in arch/parisc somewhere.  Where's the right
> place these days?

Good question...
I prefer the solution used by powerpc.
See the checkbin dependency of archprepare:

archprepare: is only triggered when we actually try to build a kernel,
and will not trigger for the said headers_install thing.

	Sam

Re: parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]

[Robert P. J. Day]

On Wed, 10 Oct 2007, Matthew Wilcox wrote:

> On Wed, Oct 10, 2007 at 08:38:58PM +0200, Sam Ravnborg wrote:
> > parisc arch Makefile needs some love and care...
>
> None of your comments actually address the thing that he was having
> problems with:
>
> ifneq ($(call cc-ifversion, -lt, 0303, "bad"),)
> $(error Sorry, GCC v3.3 or above is required.)
> endif
>
> Now, compiler.h has some checks like:
>
> #elif __GNUC__ == 3 && __GNUC_MINOR__ >= 2
> # include <linux/compiler-gcc3.h>
> #else
> # error Sorry, your compiler is too old/not recognized.
> #endif
>
> But it doesn't permit us to rule out gcc 3.3 unless we patch compiler.h.
> There's no asm/compiler.h, for example.

hmmmm ... actually, there is ... sort of:

$ find include -name compiler.h
include/asm-alpha/compiler.h
include/asm-mips/compiler.h
include/linux/compiler.h

$ grep -r "asm/compiler.h" *
arch/mips/kernel/cpu-bugs64.c:#include <asm/compiler.h>
arch/mips/kernel/time.c:#include <asm/compiler.h>
arch/mips/au1000/common/time.c:#include <asm/compiler.h>
arch/alpha/kernel/sys_sio.c:#include <asm/compiler.h>
include/asm-alpha/mmu_context.h:#include <asm/compiler.h>
include/asm-alpha/core_marvel.h:#include <asm/compiler.h>
include/asm-alpha/core_t2.h:#include <asm/compiler.h>
... lots more alpha stuff ...

  so there does appear to be some precedent for an asm/compiler.h.
for better or worse.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

[matthew@wil.cx: Re: [parisc-linux] parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]]

[Matthew Wilcox]

Sam mipslet 'parisc-linux' in the first mail ... so i replied to the
second mail ... without checking l-k was still cc'd.

----- Forwarded message from Matthew Wilcox <matthew@wil.cx> -----

From: Matthew Wilcox <matthew@wil.cx>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] parisc arch makefile clean-up needed [Was:
	cleaning up "make headers_install" for various architectures]

On Wed, Oct 10, 2007 at 08:42:25PM +0200, Sam Ravnborg wrote:
> parisc arch Makefile needs some love and care...
> 
> The logic selecting CROSS_COMPILE seems fishy and wrong -
> the error reported by rday is obvious in this respect.

He doesn't have a compiler installed that can target parisc.  It doesn't
seem obvious to me that this should work.

> FINAL_LD is unused - kill it.

OK.

> Building with oldpalo has been broken for a loong time - time to kill it?
> Hint - the "cd ../palo" is not working as expected.
> And use of TOPDIR is deprecated.

OK, killed.  I don't think anyone still uses that.

> The libs-y assignment should learn from the other architectures how to
> get the gcc lib filename:
> $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)

Actually, this looks utterly unstandardised:

arch/cris/Makefile:LIBGCC = $(shell $(CC) $(CFLAGS) -print-file-name=libgcc.a)
arch/h8300/Makefile:LIBGCC := $(shell $(CROSS-COMPILE)$(CC) $(CFLAGS) -print-libgcc-file-name)
arch/m32r/Makefile:LIBGCC       := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
arch/parisc/Makefile:libs-y     += arch/parisc/lib/ `$(CC) -print-libgcc-file-name`
arch/sh64/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
arch/sh/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)

How about we set it in the main Makefile, or one of the ones in
scripts/?  That way we don't have to learn why $(shell $(CC) $(CFLAGS)
-print-libgcc-file-name) is superior to `$(CC) -print-libgcc-file-name`

> 
> And this snippet is also wrong:
> PALO := $(shell if which palo; then : ; \
> 	elif [ -x /sbin/palo ]; then echo /sbin/palo; \
> 	fi)
> 
> palo: vmlinux
> 	@if [ -x $PALO ]; then \
> 
> 
> Make does not export variables so $PALO is not the same as $(PALO).
> The latter should be used.

Huh.  Looks like the sense of the test is reversed too.  That should
probably be:

	@if [ ! -x $(PALO) ]; then \

> I did not supply a patch because I do not fully understand the
> logic behind setting CROSS_COMPILE and 64BIT or not.
> But I will be happy to review a patch to fix the issues in the
> parisc Makefile.

One issue is that we don't have native 64-bit userspace on parisc.
And we don't have a toolchain that you can pass -m32/-m64 to; you have
to explicitly build a hppa64-linux-gnu toolchain.  Another thing we try
and make user-friendly is that if you're building the parisc kernel on
a non-parisc machine, you need to use a cross-compiler, so we autodetect
that case for you.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

----- End forwarded message -----

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]

[Sam Ravnborg]

> On Wed, Oct 10, 2007 at 08:42:25PM +0200, Sam Ravnborg wrote:
> > parisc arch Makefile needs some love and care...
> > 
> > The logic selecting CROSS_COMPILE seems fishy and wrong -
> > the error reported by rday is obvious in this respect.
> 
> He doesn't have a compiler installed that can target parisc.  It doesn't
> seem obvious to me that this should work.

We have at least the header_install target where it makes sense
to continue with a gcc that is not for the architecture being build.

So plain gcc (aka no CROSS_COMPILE) should be the fallback
solution. This fallback is anyway what most architectures use.


> > The libs-y assignment should learn from the other architectures how to
> > get the gcc lib filename:
> > $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> 
> Actually, this looks utterly unstandardised:
> 
> arch/cris/Makefile:LIBGCC = $(shell $(CC) $(CFLAGS) -print-file-name=libgcc.a)
> arch/h8300/Makefile:LIBGCC := $(shell $(CROSS-COMPILE)$(CC) $(CFLAGS) -print-libgcc-file-name)
> arch/m32r/Makefile:LIBGCC       := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> arch/parisc/Makefile:libs-y     += arch/parisc/lib/ `$(CC) -print-libgcc-file-name`
> arch/sh64/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> arch/sh/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> 
> How about we set it in the main Makefile, or one of the ones in
> scripts/?  That way we don't have to learn why $(shell $(CC) $(CFLAGS)
> -print-libgcc-file-name) is superior to `$(CC) -print-libgcc-file-name`

cris lacks a major rehaul - planned in this merge window. Will sync it when done.
h8300 should not use CROSS_COMPILE - a bit confused here.

And the reason why $(shell ) is preferred over backticks is simple.
We almost never use backticks in the kernel Makefile since the $(shell )
syntax is more obvious and I like it this way.

	Sam