On Mon, Jul 10, 2006 at 01:22:05PM -0400, Jesse Keating wrote: > On Monday 10 July 2006 13:10, Jesse Keating wrote: > > libtool stuff got accepted upstream so the mass rebuild will start tomorrow > > (after a maint window that effects one of our build arches). Let the good > > times roll. > > Er, not libtool, but rather binutils, linker and glibc improvements for much > faster dynamic lib loading. The binutils side is already approved and we are just polishing the binutils and glibc patches now, should take just a few hours. But there is a question how to enable this and what defaults should be used, and that's something where wider input is desirable. Just a quick note what changed: In ELF, .hash section (with DT_HASH dynamic tag pointing to it) is used during dynamic linking for symbol lookup, the dynamic linker for each symbol it needs to resolve uses that section to map it to a set of symbol indexes of possible symbol definitions. We wrote changes that introduce a new section (.gnu.hash, DT_GNU_HASH dynamic tag) that serves the same purpose, but is much more efficient (gives far fewer symbol definition candidates and uses far fewer cachelines). The dynamic linker in glibc will, starting with tomorrow's build, use DT_GNU_HASH if it exist and fallback to DT_HASH if it does not. ld has new option, --hash-style: --hash-style=sysv (the default) creates just the old .hash section (i.e. no change from current behavior) --hash-style=both creates both .hash and .gnu.hash section (advantage is that libraries/binaries linked with this option can be used both with any dynamic linker and the new one will be able to use the optimized .gnu.hash section). Disadvantage is that it wastes disk space and more importantly memory in the apps (although the mapping is just read-only, it still occupies address space, etc.). --hash-style=gnu creates just the .gnu.hash section and not .hash. Such binaries or shared libraries can be only used with the new glibc dynamic linker. Now, I think it would be good to use --hash-style=gnu in most of our packages, after all, during FC5 rebuilt everything was built with -fstack-protector and therefore basically all packages rely on libc.so.6(GLIBC_2.4) and can't be used on older distros either. One exception perhaps should be libraries dlopened by statically linked binaries (so, essentially a subset of glibc libraries and nss_* package shared libraries). The question is, should that be the default gcc enforces for everybody (i.e. if you compile your own proglet in FC6, is it ok if it only has .gnu.hash section and not .hash?) or should that be only selected from redhat-rpm-config passed flags? Also, I guess we should add Provides: ld-linux.so.2(GNU_HASH) (and similar for other arch dynamic linkers) to glibc that supports this and for packages built with --hash-style=gnu (i.e. if they have DT_GNU_HASH dynamic tag and not DT_HASH) automatically add the corresponding Requires. Jakub
