Lpc2000

miruffer wrote:

>Hi,
>
>thank you very much for your explanation and the provided source code,
>but I think you misunderstood me. I have written the routines _write_r
>and _read_r and so on. I compiled these new written functions and
>build my own small library called libosarm.a . If I disassemble this
>library there is the correct assembler code inside. But if I link my
>project with arm-elf-gcc $FLAGS -o tst *.o -Wl,-verbose -losarm I can
>see that the linker opens my library, but after that he opens libc.a
>and shows the errors.
>
>  
>

Then try this:

arm-elf-gcc $FLAGS -o tst *.o -Wl,-verbose -lc -losarm


Tell it to link in libc, then libosarm.  It should then link in libc, 
then look to subsequent libraries to resolve the missing references for 
libc.  The linker works from left to right, symbols unresolved at that 
point, are found only in subsequent libraries, not in the the previous 
ones.  I have abandoned the use of code archives in my project because 
the linking order got too wacky:

INPUT( -lc -lsystem -lc -liface -lc -lmmc -lc -luarts -liface -lc -lstdc 
-lgcc );

At that point, I felt there must be a better way! :(   There was, 
eliminate all those stupid archives.  But, then I was faced with the 
problem of how to build a list of object modules to link together.  This 
is my project tree:

EvntCPU/
|-- facp
|   |-- datatest
|   `-- include
|-- iface
|   `-- include
|-- include
|-- mmc
|   `-- include
|-- setup
|   |-- include
|   `-- menuSrc
|-- system
|   `-- include
|-- uarts
|   `-- include
`-- upgrade

There are 73 object files that need to be link, these mostly in the 
child directories off the project root.  What I needed to do was have 
something that told gcc to link all the object files.  But the only way 
I could think to do this was to give a list of all of them, complete 
with path/object.o references.  The solution to that is in the Makefiles.

================== project Makefile ===================
export LINKOBJS=.linkobjs

MODULE_DIRS = setup iface system facp mmc uarts

# Default target.
all: announce buildModules build

announce:
   @echo "** Building EVNT(2138)"

buildModules:
   @rm -f $(LINKOBJS)
   @for subdir in $(MODULE_DIRS) ; do \
      $(MAKE) -C $$subdir ; \
   done

build: elf bin lss sym

=============== end ===================

As each of the MODULE_DIRS are built, the append a list of object files 
into the main list.  This file is then used when linking.  Here is how I 
create that list of objects within each MODULE_DIRS:


========== subdir Makefile ======================

ifndef $(PROJSUBDIR)
PROJSUBDIR=$(shell /bin/pwd)/../
endif

CURSUBDIR=$(shell /bin/pwd | sed 's:/.*/::')
DEPEND=$(PROJSUBDIR)/.depend

SRCS := $(wildcard *.c)
OBJS := $(patsubst %.c,%.o,$(SRCS))
LOBJS := $(patsubst %.c,$(CURSUBDIR)/%.o,$(SRCS))


all: announce $(OBJS) finish

finish:
   echo -n "$(LOBJS) " >> ../$(LINKOBJS)

announce:
   @echo "   Building iface"

%.o: %.c
   $(CC) $(EXTRAINCS) $(THUMB) $(THUMB_IW) $(OPTNONE) $(ALL_CFLAGS) -c 
$< -o $@
   touch $(DEPEND)

=========== end ========================

LOBJS is the key.  When the finish rule is run, it appends to the main 
list all the object files with the current dir.  This occurs  for each 
and every MODULE_DIRS dir.  Ultimately, back at the main project 
Makefile we link everything to make the elf file:

==============  project Makefile =====================

%.elf: $(OBJ) $(DEPEND)
   $(CC) $(OPTNONE) $(ALL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS) `cat 
$(LINKOBJS)`


=============== end =======================

Note the backticks surrounding the cat $(LINKOBJS), effectively the 
contents of the file containing all those object filenames we collected 
appear there.   Also notice the $(DEPEND), that is used as a build flag 
file.  When a subdir compiles a new object file, it touches (dates + 
time) the depend file.  Later, the depend file is used within the ELF 
rule to see if linking is required (build a new elf image).

If you haven't mastered the Makefiles yet, do so.  It does take some 
work to get them to make sense, but the ability to create / manipulate 
your own make system is well worth the effort!  Especially if you plan 
on continuing to do more than blink an LED.  ;-)

We don't need no stinkin' archives!


TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------