[uClibc]crt0.o vs crt1.o

[Stefan Allius]

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

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.

So we can support both calling conventions without reconfiguring/rebuilding 
the uClibc. A compiler (and the uClibc wrapper) can decide between crt0.o 
crt1.o. For the GCC/uClibc toolchains, the crt0/1.o decision can depend on 
compiler options like: -static, -shared or -nostartfiles. 

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

What do you think ?

If you want I will make a patch, which build the discribed versions of crt0.o 
and crt1.o.

Bye Stefan


-- 
----------------------------------
Stefan Allius
senior software engineer

ATecoM GmbH
advanced telecommunication modules
Kaiserstrasse 100
D-52134 Herzogenrath
Germany

Tel: +49/2407/9586-0
Fax: +49/2407/9586-44
eMail: allius at atecom.com
URL: http://www.atecom.com
----------------------------------