After prelinking your entire system, everything works fine. But the after effects are that LD_PRELOAD causes the following error with libsandbox.so, ./usr/qt/3/bin/moc: error while loading shared libraries: unexpected reloc type 0x05 This shows the libsandbox.so is zapping all the exec's. I have made a zapped version of sandbox which does nothing, then emerge works. I call for a sandbox replacement, I have a large list of breakages, and LD_PRELOADing will always break things ..
Ok, be so kind to code one =)
We do need one. Unfortunately, we don't seem to have anybody willing to write on right now. If you're interested, I know that karltk has had thoughts about how to use strace as the base for a new sandbox, but he can't work on it until after the first of the year. If anybody is interested, I'm sure that Karl would be more than willing to share what he knows.
I wrote a prelim sandbox that uses ptrace, please see my comments on bug 9403.
Clear description of problem: If you use prelink on a few (1 atm) executables and run them with LD_PRELOAD set then they crash/fail to run with the following error: error while loading shared libraries: unexpected reloc type 0x05 I have only found this happening for /usr/qt/3/bin/moc so far. The great majority of apps run fine. Its not a great problem. I guess this is because the overwriting of symbols confuses /lib/ld-2.3.1.so and it's prelink process. I will email the libc mail list for more info. I think LD_PRELOADing will always cause problems no matter what library you use. I think the idea to use a user portage during make will be cool, saving the LD_PRELOAD for the install part. It will fix the majority/all of the problems. Other than that prelinking in portage works fine. If you put prelink "${x}" in prepallstrip, then all installed binaries are prelinked by default. Not all binaries can be prelinked so prelink will print a few errors, but in that case it will do nothing to the executable which is fine. I have encountered no errors except for this one. Prelink requires up2date binutils and glibc (the latest versions) Note that I have put a masked ebuild in portage for prelink for your breaking pleasure!
The fix has been added to glibc by Jakub Jelinek. It was a glibc bug afterall. The fix can be found at: http://sources.redhat.com/ml/libc-alpha/2002-11/msg00151.html Add it to the next glibc -r revision and prelinking in portage will be ready with a few small portage patches.