[U-Boot-Users] Question on examples compiling
Hello,
I'm just writing a support for a new board based on mips (au1100) and I cannot understand why I have to apply this patch:
diff --git a/examples/Makefile b/examples/Makefile index fee2674..b732318 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -60,7 +60,7 @@ endif include $(TOPDIR)/config.mk
SREC = hello_world.srec -BIN = hello_world.bin hello_world +BIN = hello_world hello_world.bin
ifeq ($(CPU),mpc8xx) SREC = test_burst.srec @@ -122,7 +122,7 @@ clibdir := $(shell dirname `$(CC) $(CFLA
CPPFLAGS += -I..
-all: .depend $(OBJS) $(LIB) $(SREC) $(BIN) +all: .depend $(OBJS) $(LIB) $(BIN) $(SREC)
######################################################################### $(LIB): .depend $(LIBOBJS)
in order to have files into example directory to be compiled? =:-o
Rodolfo
In message 20060410220714.GA21613@enneenne.com you wrote:
I'm just writing a support for a new board based on mips (au1100) and I cannot understand why I have to apply this patch:
...
in order to have files into example directory to be compiled? =:-o
Because your toolchain (especially the "make" command) is seriously broken.
Best regards,
Wolfgang Denk
On Tue, Apr 11, 2006 at 12:57:22AM +0200, Wolfgang Denk wrote:
Because your toolchain (especially the "make" command) is seriously broken.
I'm using this version (default Debian unstable):
giometti@zaigor:~$ make --version GNU Make 3.81rc2 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This program built for i486-pc-linux-gnu
Is this version broken?
Rodolfo
In message 20060410231500.GC21613@enneenne.com you wrote:
I'm using this version (default Debian unstable):
-----------------------------------------^^^^^^^^^
Do I need to say more?
giometti@zaigor:~$ make --version GNU Make 3.81rc2
...
Is this version broken?
Just try a stable version, and you will not need to ask.
Yes, it is broken. See previous reports on this list. Anything up to and including 3.80 seems to be fine. 3.81 and later seems to be broken.
Best regards,
Wolfgang Denk
Wolfgang Denk writes:
Rodolfo> I'm using this version (default Debian unstable): Wolfgang> -----------------------------------------^^^^^^^^^
Wolfgang> Do I need to say more?
I won't exaggerate. Debian `unstable' is stable enough even for production use. For really unstable version, you have to use `experimental.'
Rodolfo> giometti@zaigor:~$ make --version GNU Make 3.81rc2
Rodolfo> Is this version broken?
Wolfgang> Just try a stable version, and you will not need to ask.
Wolfgang> Yes, it is broken. See previous reports on this Wolfgang> list. Anything up to and including 3.80 seems to be Wolfgang> fine. 3.81 and later seems to be broken.
There are many discussions about what's really broken - make or Makefiles. The 3.81 caused entire Linux kernel to compile each time any single file was changed. Make developers claim it's a kernel Makefiles problem. Fortunately, for the specific problem which is discussed here the future outcome of this argument does not matter because there is a simple fix. I changed the order of dependencies in the examples/Makefile and the problem disappeared. I have no time to investigate if it's make or Makefile problem (though I personally think it's the latter). I attached the diff just in case you'd like to use it.
Dear Yuli,
in message 17467.38648.750449.731249@astp0002.localdomain you wrote:
I won't exaggerate. Debian `unstable' is stable enough even for production use. For really unstable version, you have to use
Did you ever try to explain this to any manager in a company with more than 200 employees? But agreed, that's off topic here.
There are many discussions about what's really broken - make or Makefiles. The 3.81 caused entire Linux kernel to compile each time any
It is *obviously* make which is broken.
problem. Fortunately, for the specific problem which is discussed here the future outcome of this argument does not matter because there is a
Yes, it does matter. Broken tools are a serious problem to all of us, especiallyu when it's such basic tools as make ot gcc or ld.
simple fix. I changed the order of dependencies in the examples/Makefile and the problem disappeared. I have no time to investigate if it's make or Makefile problem (though I personally think it's the latter). I
No. The result of a make run MUST NEVER depend on the order of the dependencies. This is plain unacceptable to me. I'm not even going to discuss this.
Best regards,
Wolfgang Denk
participants (3)
-
Rodolfo Giometti -
Wolfgang Denk -
Yuli Barcohen