Re: [avr-gcc-list] Building AVARICE on Cygwin

[Joerg Wunsch]

As "Ralph Mason" <address@hidden> wrote:

>I don't really understand why the complier generated an object file stops it
>from linking (what else would the linker work with?) Does not the -l get
>passed to the linker?

Yes, the -l is a linker option.  The linker collects object modules.
First, it collects all the .o modules explicitly named on the command
line.  Then, it'll use the .a files to pick up further modules
(precompiled .o files) from these libraries, but /only/ to satisfy
symbols that are still undefined at this point in time.

So in your example (let's assume the object file be named test.o for
simplicity):

ld [...] -lbfd test.o [...] -lc -lgcc -lc

by the time test.o is seen, it generates an undefined reference to
_bfd_init, but no library follows on the command line that could
resolve this symbol.  The library that's supposed to resolve it came
/before/ the symbol was even marked undefined.

>How actually could I make this link?

One way (the usual one):

ld [...] test.o -lbfd [...] -lc -lgcc -lc

or expressed in a call to cc

cc test.c -lbfd

Another way (the not so obvious one) is:

ld [...] -u _bfd_init -lbfd test.o [...] -lc -lgcc -lc

(or: cc -Wl,-u,_bfd_init -lbfd test.c)

In the latter case, you explicitly mark _bfd_init as `undefined'
before linking libbfd.a, that way the respective module will already
be picked up from there even though your actual reference (in test.o)
has not yet been seen.  That's not the usual way to arrange for it,
but if you e. g. look into the documentation for avr-libc's printf()
family, you can see that this trick is needed for example to get the
floating point vfprintf() from another library.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/