Date: Mon, 3 Jun 2002 17:52:51 -0400
Message-Id: <200206032152.g53Lqpo30071@envy.delorie.com>
X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT delorie DOT com using -f
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp AT delorie DOT com
In-reply-to: <3cfbd767$0$8376$9b622d9e@news.freenet.de> (deckerben@freenet.de)
Subject: Re: DXE2GEN: unresolved symbol
References: <3cf910c2$0$23731$9b622d9e AT news DOT freenet DOT de> <1022961734 DOT 321994 AT queeg DOT ludd DOT luth DOT se> <3cfa9b99$0$26987$9b622d9e AT news DOT freenet DOT de> <adf6bu$ku4$1 AT antares DOT lu DOT erisoft DOT se> <3cfbd767$0$8376$9b622d9e AT news DOT freenet DOT de>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> 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.