On Fri, Apr 04, 2003 at 10:18:39AM -0500, Bill Rugolsky Jr. wrote: > On Fri, Apr 04, 2003 at 03:37:35AM -0500, Jakub Jelinek wrote: > > The reason why it is not enabled in Shrike is that it was not enabled > > early enough in the beta cycle (at that point prelink did not work > > with TLS in libc, so could not be enabled). > > I hope we'll enable it in the next beta cycle. > > Jakub, > > When you say "not enabled" do you mean that the distro itself was > not prelinked in the distributed RPMS? Is that the intention for It cannot be. prelinking depends on the exact mix of packages/other libs you have on your system. The only thing which can be done (and already is) is to prelink --reloc-only libc.so to a preferred address, so that the thousands of R_386_RELATIVE relocs can be skipped even when prelink was not used. But doing it for more than that single library starts to be problematic, remember a.out shared library offsets registry? When prelink is run, it picks up the offsets uniquely for each system. > future releases -- to distribute the executable code in the RPMS > prelinked so it "just works"? > > In RHL 8.0, it was taking me about 25 seconds to re-login into GNOME > (i.e., with a warm cache) on an 800 MHz Celeron. So I prelinked, but > noted that there were lots of GNOME-related lib warnings about implicit > dependencies, so I didn't expect much speed up. Nevertheless, this > reduced re-login to 6-7 seconds. There are various warnings prelink can emit, some of them are more serious (and usually result in some library or binary not being able to be prelinked), some are less severe (e.g. non-weak undefined symbols not defined in symbol scope of particular shared library, which just mean there will be more prelink conflicts than really necessary; that is hint to library authors to think about their code). Jakub
