← Back to team overview

elementary-dev-community team mailing list archive

Re: Prelink


2012/5/10 Sergio <sertorbe@xxxxxxxxx>

>  About the part where you say that maybe an application won't like it and
> we may end up with an "unexecutable", prelink skips incompatible apps (if
> you want i can send you a log from prelink working in my PC).
I know it does attempt a graceful failure, but it doesn't always work, as
that Glib example shows. And accodring to this
such issues still happen with some modern libs. Maintaining an internal
blacklist of things which should not be prelinked, compiled by trial and
error doesn't seem to be a good idea.

Also, that thread suggests that prelink works only on 32bit systems. I got
tired of rumors and tried to find some official documentation on Prelink.
All I've got is a manpage and a
paper<http://people.redhat.com/jakub/prelink/prelink.pdf>dating back
to 2004 - not very reassuring. In additon, I've stumbled upon
this: "It has been observed that if you are low on disk space and you
prelink your entire system then there is a possibility that your binaries
may be truncated. The result being a b0rked system" at
Too bad we don't know how much space it will need to avoid such disasters.

And "When I prelink my system some static binaries don't work anymore" at
http://www.gentoo.org/doc/en/prelink-howto.xml isn't very reassuring
either, and even though static linking shouldn't be used, IRL it happens.

> I agree with you in the case of shutdown or blackout, however prelink can
> delete the prelink in a executable as easy as can put it.
I suspect it won't work on a broken executable. Either way, did I
understand correctly that you suggest the user to acknowledge that the
issue is in failed prelinking and revent the prelinking manually via a
terminal command, while the user is A) not aware of prelink's existence and
B) most likely doesn't know anything about terminal? (that's our target

> Also when i have some time (maybe this weekend) i will try to do some
> benchmarks in order to see wether it has a important impact or not.

Looking forward to it. Please run the tests in identical environments to
eliminate interference from preload and various kernel caching stuff, e.g.
from a virtual machine saved state. This mail from Preload's original
developer suggests a reproducible testing technique:

But however good or bad the result is, I seriously doubt we'll ever tackle
it because of all the issues listed above. I'd much rather hit up on
something from this list:

Sergey "Shnatsel" Davidoff
OS integrator @ elementary

Follow ups