[uClibc]Re: crt0.o vs crt1.o
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 B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
More information about the uClibc