make[1]: *** No rule to make target hello_world.srec', needed byall'. Stop.
This appears to come from the examples/Makefile. This is called in the primary makefile for $(SUBDIRS) target resolving to doing make -C examples all
Commenting out each filename added to the SREC variable list moves this error to the next srec filename.
Though the examples/Makefile does seem to have a %.srec target...
Anonymous
If I add a new target to the root Makefile, I am able to build examples/hello_world and then examples/hello_world.srec:
hack1:
$(MAKE) -C examples hello_world
hack2:
$(MAKE) -C examples hello_world.srec
and then do
make hack 1
The hello_world fileis made which is prerequisite to hello_world.srec
make hack2
The hello_world.srec file si made.
So the %.srec target in the examples/Makefile should be working.:/
Hmmm, regarding previous comment experiment.
If I do
make hack1
make hack2
in order, then it works and I have the hello_world.srec file, but first making its prerequisite file hello_world.
If I have neither file, and go sttraight to making hello_world.srec
make hack2
then I again have the error:
make -C examples hello_world.srec
make[1]: Entering directory
/home/bill/projects/uboot_thomas/u-boot/examples' make[1]: *** No rule to make targethello_world.srec'. Stop.make[1]: Leaving directory `/home/bill/projects/uboot_thomas/u-boot/examples'
make: *** [hack2] Error 2
So it seems there must be something not happy with defining the hello_world prerequisite.
But I do not see anything obviously wrong in the makefile for that.
If one removes $(SREC) from the prerequisites for the all target, then the same error comes up for .bin files:
make[1]: *** No rule to make target
hello_world.bin', needed byall'. Stop.%: %.o $(LIB)
$(LD) -g $(EX_LDFLAGS) -Ttext $(LOAD_ADDR) \
-o $@ -e $(<:.o=) $< $(LIB) \
-L$(gcclibdir) -lgcc
%.srec: %
$(OBJCOPY) -O srec $< $@ 2>/dev/null
Patch to make examples/Makefile work with make 3.81.
According to http://www.mail-archive.com/help-make@gnu.org/msg05482.html this problem occurs with make 3.81, which is also used by the ELDK. The solution is to reorder the target dependencies, as the uploaded patch file shows.
Found a discussion of exactly this problem
http://blackfin.uclinux.org/gf/project/u-boot/forum/?_forum_action=ForumMessageBrowse&thread_id=1820&action=ForumBrowse
And another related thread
http://lists.denx.de/pipermail/u-boot/2006-July/016019.html
Collecting more info
http://lists.denx.de/pipermail/u-boot/2006-March/013908.html
http://lists.denx.de/pipermail/u-boot/2007-January/018779.html
http://lists.denx.de/pipermail/u-boot/2006-April/014422.html
Mr. Denk appears to believe this is a problem with the tool make, not a problem with the makefile nor rest of ELDK. Am I using make from ELDK or make from Kubuntu? Considering the age of these threads (2007 and older), why would make not have been fixed yet? What version # of make am I using? (They talk about make 3.80 vs 3.81)
I need to check my $PATH and make sure I'm getting the correct tools. If I am getting the correct tools, then check what may be different in modern uboot sources. (This repository is for 1.1.1 AmigaOne specific source delivery)
I think also the ELDK comes with make 3.81 (check with /path/to/eldk/usr/bin/make --version).
BTW: If you have sourced the eldk_init file before compiling U-boot, then you're probably using ELDK's make command. This script prepends the path to ELDK's /usr/bin directory to your PATH variable.
which make tells me that it's in /usr/bin/ so it's what comes with Kubuntu. make --version says it indeed is the 3.81 version that is shown to be problematic on the Denx mailing list archives. Grrr... Odd that it has not been updated in so long... (I'm now using Kubuntu Lucid Lenny 10.04 LTS which was just released a week or so ago)
bill@kubuntu64:/etc/X11$ which make
/usr/bin/make
bill@kubuntu64:/etc/X11$ make --version
GNU Make 3.81
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 x86_64-pc-linux-gnu
So,
I don't see an eldk_init file anywhere (tried using find in my /opt/eldk install dir). I manually prepended the paths in my .bash_profile. And yes, my eldk make is also 3.81. They must have accepted that this is what it will be and changed the makefile somewhere along the line. I cannot find reference to eldk_init in the ELDK manual either. Is this for using eldk, or for compiling it? (I did find it in the git repository for ELDK sources)
I've so far only installed the ppc eldk. Currently installing ppc64 and will then do arm for kicks. Not there from ppc64 install.
I do see mention of this script on a texas instruments web page
http://processors.wiki.ti.com/index.php/ELDK_usage
I'm using ELDK 4.2 for ppc and ppc64, no arm yet. What all do you have to see this script?
In my sandbox I changed the %.srec and %.bin target dependencies from % to %.o as shown at
http://lists.denx.de/pipermail/u-boot/2006-April/014422.html
This will likely be a moot thing as we progress and take in modern stuff from the denx repository, but I do want to see stuff compiling as closely as possible to as it was delivered to us.
This is the content of my ELDK root directory:
drwxr-xr-x 2 geri geri 4096 9. Sep 2009 bin
-rw-r--r-- 1 geri geri 1003 9. Sep 2009 eldk_init
drwxr-xr-x 5 geri geri 4096 9. Sep 2009 etc
drwxr-xr-x 16 geri geri 4096 9. Sep 2009 ppc_4xx
drwxr-xr-x 16 geri geri 4096 9. Sep 2009 ppc_6xx
lrwxrwxrwx 1 geri geri 7 9. Sep 2009 ppc_7xx -> ppc_6xx
lrwxrwxrwx 1 geri geri 7 9. Sep 2009 ppc_82xx -> ppc_6xx
drwxr-xr-x 16 geri geri 4096 9. Sep 2009 ppc_8xx
drwxr-xr-x 2 geri geri 4096 9. Sep 2009 sbin
drwxr-xr-x 10 geri geri 4096 9. Sep 2009 usr
drwxr-xr-x 5 geri geri 4096 9. Sep 2009 var
-rw-r--r-- 1 geri geri 95 9. Sep 2009 version
As far as I can tell the eldk_init file is created automatically by the install script.