Re: patch to make init_array work (2nd version; resend)

[Roland McGrath <roland at frob dot com>]

When this approach came up before, Ulrich also objected to the implementation,
see http://sources.redhat.com/ml/libc-alpha/2002-03/msg00063.html.
In future repostings of patches previously discussed, it would be helpful
if you could cite the prior posting and discussion in the mailing list
archives, for the benefit of people like me who were not involved in the
discussion the first time around.

For dynamic executables, the dynamic linker or libc could in fact examine
the DT_INIT_ARRAY slots directly, rather than having the crt1.o code supply
the values.  I think this is what Ulrich wanted to see from what he said in
the message cited above.

The same is true of DT_INIT/DT_FINI, but for whatever reason the convention
inherited from SVR4 is to have the startup code call its own _init and
_fini entry points rather than the dynamic linker doing it.  

That suggested approach is not available for static linking, however.  We
need to keep the same crt1.o code for both static and dynamic linking (or
else all go raving mad).  So it is not entirely clear to me what exact
criteria the ideal solution should meet.

I am inclined to think the plan we discussed yesterday is the best one.
But if Ulrich prefers to have ld.so or libc look up DT_INIT_ARRAY et al,
then I would like to hear his thoughts on the plan for static linking.



Thanks,
Roland