[U-Boot-Users] Question on examples compiling

[U-Boot-Users] Question on examples compiling

[Rodolfo Giometti]

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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] Question on examples compiling

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A rolling stone gathers momentum.

[U-Boot-Users] Question on examples compiling

[Rodolfo Giometti]

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 at 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

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060411/09f17c28/attachment.pgp 

[U-Boot-Users] Question on examples compiling

[Wolfgang Denk]

In message <20060410231500.GC21613@enneenne.com> you wrote:
> 
> I'm using this version (default Debian unstable):
-----------------------------------------^^^^^^^^^

Do I need to say more?

>    giometti at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The more complex the mind, the greater the need for the simplicity of
play.
	-- Kirk, "Shore Leave", stardate 3025.8

[U-Boot-Users] Question on examples compiling

[Wolfgang Denk]

In message <20060411020747.37569.qmail@web508.biz.mail.mud.yahoo.com> you wrote:
> 
> I then tried again from the problem machine and U-boot
> built fine.  Since then, the make problem has
> mysteriously gone away, even in other build areas.

Did you really run a "make mrproper" in the U-Boot tree, or otherwise
made sure you really started with a clean tree without old  pre-built
(and eventually bad) build results?

Note that you must run the "make mrproper" using  the  old  (working)
make  -  chances  are  that  the  clean  step will also fail, leaving
unwanted files around.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                 -- Wernher von Braun

[U-Boot-Users] Question on examples compiling

[Yuli Barcohen]

>>>>> 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 at 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.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================
-------------- next part --------------
Index: examples/Makefile
===================================================================
RCS file: /home/CVS/u-boot/u-boot/examples/Makefile,v
retrieving revision 1.1.1.12.2.3
diff -p -u -r1.1.1.12.2.3 Makefile
--- examples/Makefile	29 May 2005 19:40:40 -0000	1.1.1.12.2.3
+++ examples/Makefile	11 Apr 2006 11:37:37 -0000
@@ -56,39 +56,39 @@ 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
-BIN	= test_burst.bin test_burst
+BIN	= test_burst test_burst.bin
 endif
 
 ifeq ($(ARCH),i386)
 SREC   += 82559_eeprom.srec
-BIN    += 82559_eeprom.bin 82559_eeprom
+BIN    += 82559_eeprom 82559_eeprom.bin
 endif
 
 ifeq ($(ARCH),ppc)
 SREC   += sched.srec
-BIN    += sched.bin sched
+BIN    += sched sched.bin
 endif
 
 # The following example is pretty 8xx specific...
 ifeq ($(CPU),mpc8xx)
 SREC   += timer.srec
-BIN    += timer.bin timer
+BIN    += timer timer.bin
 endif
 
 # The following example is 8260 specific...
 ifeq ($(CPU),mpc8260)
 SREC   += mem_to_mem_idma2intr.srec
-BIN    += mem_to_mem_idma2intr.bin mem_to_mem_idma2intr
+BIN    += mem_to_mem_idma2intr mem_to_mem_idma2intr.bin
 endif
 
 # Utility for resetting i82559 EEPROM
 ifeq ($(BOARD),oxc)
 SREC   += eepro100_eeprom.srec
-BIN    += eepro100_eeprom.bin eepro100_eeprom
+BIN    += eepro100_eeprom eepro100_eeprom.bin
 endif
 
 ifeq ($(BIG_ENDIAN),y)
@@ -113,7 +113,7 @@ clibdir := $(shell dirname `$(CC) $(CFLA
 
 CPPFLAGS += -I..
 
-all:	.depend $(OBJS) $(LIB) $(SREC) $(BIN)
+all:	.depend $(OBJS) $(LIB) $(BIN) $(SREC)
 
 #########################################################################
 $(LIB): .depend $(LIBOBJS)

[U-Boot-Users] Question on examples compiling

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Here is an Appalachian version of management's answer  to  those  who
are  concerned  with  the fate of the project: "Don't worry about the
mule. Just load the wagon."         - Mike Dennison's hillbilly uncle