Re: Compiling swarm-960110

[Nelson Minar]

>   There are a lot of library calls cannot be recognized during "make"ing the 
> examples in apps directory.  I duplicate the entries of LIBS in the 
> Makefile.conf several times, like the following
>  LIBS=                $(SWARMLIBS) $(SYSLIBS) $(OTHERLIBS) \
>                $(SWARMLIBS) $(SYSLIBS) $(OTHERLIBS) \
>                $(SWARMLIBS) $(SYSLIBS) $(OTHERLIBS) \
>                $(SWARMLIBS) $(SYSLIBS) $(OTHERLIBS) 
>  
>  And then, it works and the examples can be run successfully.

You shouldn't have to do that to get Swarm to compile - what are the
symbols missing when you don't duplicate the link lines?


[what follows is an explanation of how ld works, for the curious.]

The reason this might be fixing things is because ld only resolves
symbols in order. For instance, if you do this:

  gcc myProgram.o -lfoo -lbar

Then the linker first makes a list of unresolved symbols in
myProgram.o and tries to resolve them by looking through libfoo.a.  In
the process of doing this, it will come up with a new list of
unresolved symbosl - anything left over in myProgram.o, plus new
things that libfoo.a itself needs. It then takes this list and
compares it into libbar.a, resolving what it can and (possibly) coming
up with more new things that libbar.a needs. Finally it links
implicitly against libc.a, and hopefully everything is resolved.

Problems creep in if libbar.a references some symbol in libfoo.a that
wasn't linked before. Because the linker goes in order, it won't look
again in libbar.a to pick up the new symbols, and you get unresolved
references even though the symbol is defined somewhere in a library
you linked against. But if you tell it to look again in libfoo.a

  gcc myProgram.o -lfoo -lbar -lfoo

then it'll work. But it's undesireable to scan a library twice, it's slow.

Swarm has a couple of backward references that could in theory
require scanning a library twice, but we've cleverly arranged it so
that those symbols are put in .o files that were being linked anyway,
so they get carried along by fortuitious accident.


Part of the problem is that Swarm has lots of ittybitty libraries.
Eventually we'll distribute Swarm that links to one big libswarm.a,
and hopefully these problems will go away.