[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Mass Rebuild to begin tomorrow (Tuesday, July 11)



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]