> The CSU code has pretty much no idea on what the rest of the world is > going to do. It does: [...]
> There is no way with ELF to decide at link time which of those > features are used by the program and therefore no way to remove any > of them. I don't think that's true. If the program dynamically loads code, yes, it's true (or close enough). But, for a statically linked program (as pointed out upthread, dlopen doesn't work when linked static), it can be done, and with quite low otherwise-useless overhead. Using pthreads as an example, consider this. All pthreads .o modules refer to (not "call") a specific function. For concreteness, let's call it _pthreads_csu_init. _pthreads_csu_init is off in its own file; that routine does the CSU initialization for pthreads. The CSU code makes a weak reference to _pthreads_csu_init, calling it only if the weak reference was satisfied by a real definition. Of course the dynamically-linked form of pthreads would always define _pthreads_csu_init - or, alternatively, dynamic linking would use a different CSU, one which unconditionally calls _pthreads_csu_init as an ordinary reference. Is it worth doing? That's a separate question. But I have no real doubt that it could be done if desired. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
