linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* kernel makefiles broken?
@ 2002-10-02 10:40 Russell King
  2002-10-02 12:10 ` Bruce Harada
  2002-10-02 12:12 ` Adrian Bunk
  0 siblings, 2 replies; 3+ messages in thread
From: Russell King @ 2002-10-02 10:40 UTC (permalink / raw)
  To: linux-kernel

Hi,

I've noticed on two machines now that the kernel makefiles seem to have
changed their behaviour.  One x86 RH-based, and one parisc debian based.

make seems to ignores errors from gcc, and only stops when trying to link.
On a PARISC box, I've seen the build get all the way though to successfully
linking vmlinux, even with compilation failures.  Obviously not ideal,
since vmlinux may not reflect reality.

  arm-linux-gcc -Wp,-MD,./.sl82c105.o.d -D__KERNEL__ -I/home/rmk/v2.5/linux-ebsa285/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -mapcs -mapcs-32 -D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=strongarm110 -mshort-load-bytes -msoft-float -Wa,-mno-fpu -nostdinc -iwithprefix include
-I../  -DKBUILD_BASENAME=sl82c105   -c -o sl82c105.o sl82c105.c
drivers/ide/pci/sl82c105.c: In function `sl82c105_init_one':
drivers/ide/pci/sl82c105.c:287: `slc82c105_chipsets' undeclared (first use in this function)
drivers/ide/pci/sl82c105.c:287: (Each undeclared identifier is reported only once
drivers/ide/pci/sl82c105.c:287: for each function it appears in.)
/home/rmk/v2.5/linux-ebsa285/include/asm/dma.h: At top level:
drivers/ide/pci/sl82c105.h:12: warning: `sl82c105_chipsets' defined but not used
  arm-linux-gcc -Wp,-MD,./.generic.o.d -D__KERNEL__ -I/home/rmk/v2.5/linux-ebsa285/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -mapcs -mapcs-32 -D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=strongarm110 -mshort-load-bytes -msoft-float -Wa,-mno-fpu -nostdinc -iwithprefix include  -I../  -DKBUILD_BASENAME=generic   -c -o generic.o generic.c
drivers/ide/pci/generic.h:148: warning: `unknown_chipset' defined but not used
drivers/ide/pci/generic.c:84: warning: `init_setup_unknown' defined but not used
   arm-linux-ld   -r -o built-in.o cy82c693.o pdc202xx_old.o sl82c105.o generic.o
arm-linux-ld: cannot open sl82c105.o: No such file or directory
make[3]: *** [built-in.o] Error 1
make[3]: Leaving directory `/home/rmk/v2.5/linux-ebsa285/drivers/ide/pci'
make[2]: *** [pci] Error 2
make[2]: Leaving directory `/home/rmk/v2.5/linux-ebsa285/drivers/ide'
make[1]: *** [ide] Error 2
make[1]: Leaving directory `/home/rmk/v2.5/linux-ebsa285/drivers'
make: *** [drivers] Error 2


-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: kernel makefiles broken?
  2002-10-02 10:40 kernel makefiles broken? Russell King
@ 2002-10-02 12:10 ` Bruce Harada
  2002-10-02 12:12 ` Adrian Bunk
  1 sibling, 0 replies; 3+ messages in thread
From: Bruce Harada @ 2002-10-02 12:10 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel

On Wed, 2 Oct 2002 11:40:28 +0100
Russell King <rmk@arm.linux.org.uk> wrote:

> Hi,
> 
> I've noticed on two machines now that the kernel makefiles seem to have
> changed their behaviour.  One x86 RH-based, and one parisc debian based.
> 
> make seems to ignores errors from gcc, and only stops when trying to link.
> On a PARISC box, I've seen the build get all the way though to successfully
> linking vmlinux, even with compilation failures.  Obviously not ideal,
> since vmlinux may not reflect reality.

It looks like this change might have broken kbuild:

>> Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>:
>>   o kbuild: Make KBUILD_VERBOSE=0 work better under emacs

See the exchange between Adrian Bunk and Kai under the "Linux v2.5.40 - and a
feature freeze reminder" thread.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: kernel makefiles broken?
  2002-10-02 10:40 kernel makefiles broken? Russell King
  2002-10-02 12:10 ` Bruce Harada
@ 2002-10-02 12:12 ` Adrian Bunk
  1 sibling, 0 replies; 3+ messages in thread
From: Adrian Bunk @ 2002-10-02 12:12 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel

On Wed, 2 Oct 2002, Russell King wrote:

> Hi,

Hi Russell,

> I've noticed on two machines now that the kernel makefiles seem to have
> changed their behaviour.  One x86 RH-based, and one parisc debian based.
>
> make seems to ignores errors from gcc, and only stops when trying to link.
> On a PARISC box, I've seen the build get all the way though to successfully
> linking vmlinux, even with compilation failures.  Obviously not ideal,
> since vmlinux may not reflect reality.
>...

known bug, already fixed in Linus' BK tree, patch is below.

cu
Adrian


--- a/Rules.make	Tue Oct  1 21:00:23 2002
+++ b/Rules.make	Tue Oct  1 21:00:23 2002
@@ -517,13 +517,6 @@
   include $(cmd_files)
 endif

-# Emacs compile mode works best with relative paths to find files (OK
-# if verbose, as it tracks the make[1] entries and exits, etc.)
-
-ifneq ($(KBUILD_VERBOSE),1)
-  filter-output = 2>&1 | sed 's \(^[^/][A-Za-z0-9_./-]*:[ 0-9]\) $(RELDIR)/\1 '
-endif
-
 # function to only execute the passed command if necessary

 if_changed = $(if $(strip $? \
@@ -543,7 +536,7 @@
 			  $(filter-out $(cmd_$@),$(cmd_$(1)))),\
 	@set -e; \
 	$(if $($(quiet)cmd_$(1)),echo '  $($(quiet)cmd_$(1))';) \
-	$(cmd_$(1)) $(filter-output); \
+	$(cmd_$(1)); \
 	$(TOPDIR)/scripts/fixdep $(depfile) $@ $(TOPDIR) '$(cmd_$(1))' > $(@D)/.$(@F).tmp; \
 	rm -f $(depfile); \
 	mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd)


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-10-02 12:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-02 10:40 kernel makefiles broken? Russell King
2002-10-02 12:10 ` Bruce Harada
2002-10-02 12:12 ` Adrian Bunk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).