[patch] init_array/fini_array support
Peter S. Mazinger
ps.m at gmx.net
Mon Jan 30 09:25:15 UTC 2006
On Sun, 29 Jan 2006, Joseph S. Myers wrote:
> On Tue, 24 Jan 2006, Joakim Tjernlund wrote:
>
> > > What do you think of the size increase? Couldn't we move at
> > > least some of it to ld.so? Is there some other reason to have
> > > them local in the binary?
> >
> > That's an interesting idea, but not so easy I think. One would have to move
> > the apps _init/_fini processing to ld.so and remove them from crt1 or some combination
> > of both to support static linking.
>
> Indeed, static binaries need __libc_csu_fini so avoiding it altogether for
> dynamic binaries (instead calling destructors from ld.so) would mean
> different copies of crt1 for static and dynamic linking.
I am not thinking of providing different crt1.o files. Now we put one copy
into nonshared.a (for dynamic binaries) and one into libc.a for static
binaries. So the static binaries would be the same. Where we could save
some size are the dynamic binaries only, moving it out of nonshared.a.
Would it be possible to add __libc_csu_init/fini to libc.so, or is it too
late/early? Is there a specific reason to have it in nonshared.a
(we don't have to mimic glibc for this) ? Does each binary have to have
it's own copy of it?
Under current circumstances I would rather add this patch conditionally
guarded by a config option (due to the size increase in each binary)
Thanks, Peter
--
Peter S. Mazinger <ps dot m at gmx dot net> ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
More information about the uClibc
mailing list