This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: initfini.c -> crt[in].S
> I think that would be a bad idea; we should try to keep things working on
> all libc platforms at every commit (at least to the extent of building OK
> and most tests passing) to avoid breaking things for anyone who happens to
> want to test and contribute a patch while things are in flux, and to keep
> bisection working optimally to find when problems were introduced.
That's a reasonable ideal. But it only really matters in practice if the
interim state persists for more than a short while. It persisting is a
danger if we allow it to begin at all.
If there is a firm deadline for the kludgery going away, then I am less put
out by it. But I'm still not convinced. Either we can just get all the
arch maintainers to supply the new code in short order, or else the claim
that the kludge won't persist for a long time is manifestly false.
> I don't see any great advantage either way, and it seems better to me to
> do things simply until we have multiple architecture versions and can see
> better just how much is actually common between the ways they do things.
> If at that point it seems useful to have a single pt-crti.S - if there
> really is enough in common - it will be easy enough to do the refactoring
> without needing expertise in all architectures.
It's obvious that there need only ever be a single pt-crti.S. Its sole
purpose for being is the one simple difference from the vanilla crti.S.
It's easy to get the parameterization right from the beginning. It's a
clear advantage not to need yet another fiddly per-machine file in nptl.