Mail Archives: djgpp/2002/06/03/18:59:56
> Hmmm.... that means that symbols must be defined in a
> start-to-finish fashion, right? That is, an extern symbol required
> by an object file declared in a gcc command line must be defined by
> an object file/library that is declared *later* in the same command
> line?
Libraries only. Objects are *always* included so it doesn't matter
what order you give them, relative to each other. Except for crt0.o
which must be first, since it does special things.
> Does this also determine the order in which each individual library
> file is called in the gcc command line?
Yes.
> Does is also mean that symbols defined earlier in the ommand line
> will not be used when reading libraries/objects called later in the
> gcc command line?
Objects are always pulled in. Pulling in something causes undefined
symbols to be added to the list. As libraries are encountered,
objects within them are pulled in *if* they provide a symbol
*currently* on the undefined symbols list. That may cause more
symbols to be added to the list, etc.
> `djgpp_first_dtor'
> `djgpp_last_ctor'
> `djgpp_last_dtor'
> `djgpp_first_ctor'
> `end'
The linker itself defines those, in accordance with its linker script
(lib/djgpp.djl at the moment, or perhaps built in or elsewhere
depending on your build).
> `__djgpp_selector_limit'
crt0.o but it's a "common" definition, so ultimately the linker
creates a suitable global for it.
- Raw text -