From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: DXE2GEN: unresolved symbol
Date:	Mon, 03 Jun 2002 16:38:23 CDT
Organization:	Rice University, Houston TX
Lines:	36
Message-ID:	<3cfbe1cf.sandmann@clio.rice.edu>
References:	<3cfbd767$0$8376$9b622d9e AT news DOT freenet DOT de>
NNTP-Posting-Host:	clio.rice.edu
X-Trace:	joe.rice.edu 1023140330 22008 128.42.105.3 (3 Jun 2002 21:38:50 GMT)
X-Complaints-To:	abuse AT rice DOT edu
NNTP-Posting-Date:	3 Jun 2002 21:38:50 GMT
X-NewsEditor:	ED-1.5.9
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

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

Yes (unless it's already included; all the contents of a .o file you
specify are always included).

> Does this also determine the order in which each individual library file
> is called in the gcc command line?

Yes.

> But my biggest problem is how to define the following symbols:
> 
> `djgpp_first_dtor'
> `djgpp_last_ctor'
> `djgpp_last_dtor'
> `djgpp_first_ctor'

These are constructors and destructors; you really need to import them
from the main image (or do something special).

> čnd'
> `__djgpp_selector_limit'

end is the size of the total image; it's typically only used in 
library code doing things you can't do in a dynamic link - it would
have to be imported from the main image.

The selector limit also lives in the main image, it would have to
be imported.

> Does somebody know the code that defines them... maybe I can build a special
> library that can fill those holes.

Use the ld option to create a map; you can then see what included them.

- Raw text -