[uClibc]Re: crt0.o vs crt1.o

Erik Andersen andersen at codepoet.org
Mon Dec 2 15:57:01 UTC 2002


On Thu Nov 28, 2002 at 11:19:58AM +0100, Stefan Allius wrote:
> Hi Erik,
> 
> my understanding of the crt0/1.o stuff is, that crt0.o is used on systems 
> which didn't support constructors/destructors and are often linked staticly
> (calling uClibc_main on uClibc systems).
> 
> On new systems, like ELF tagets, C++ targets, etc.., the compiler normally 
> uses crt1.o combined with crt[i/n].o and crt[begin/end].o to support the 
> constructors (calling uClibc_start_main on uClibc systems).

Sorry its taken me a few days.  I've been trying to relax a bit
over the Thanksgiving holiday here in the US...

Anyways, I've been thinking a lot about doing this sortof thing
for the past several weeks.  I've been debating, for example,
whether to have separate crt0.S and crt1.S source files, whether
to use a symlink, a hard link, etc.

> With your new configuration option, you switch between the two versions of 
> the crt?.o's. Why we don't build the two version all times? I think the 
> nicest way is to build a crt0.o which call uClibc_main and a crt1.o which 
> call uClibc_start_main.

An excellent idea.  No I feel dumb, since this is the obviously
correct way to handle things.
> Maybe we can offer a config option which allows us to remove the crt1.o by a 
> link to the crt0.o. So we can support badly configured compilers, which want 
> a crt1.o on systems without constructors/destructors.
> ==> No CTORS/DTORS support by crt1.o [Y/n] ?

Sure.  If people disable ctors/dtors, then crt1.o should be a
copy of crt0.o.  That works nicely as well.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



More information about the uClibc mailing list