On mar, 2004-03-09 at 18:07, Andr�s Rold�n wrote: > Check the MD5 before prelinking, prelink the binary and then check it > again with prelink -y --md5. If both md5 outputs are different, it means > that prelink did change the binary. It should not since prelink > processes that kind of symbols (called "conflicts" on prelink language), > on a special way and won't prelink the binary if it can't handle the > "conflict" symbol.
You are right: $ debsums -s lxdoom [OK] $ md5sum /usr/games/lxdoom 9aec303e660a329996e2b31ae23545c6 /usr/games/lxdoom # prelink /usr/games/lxdoom $ md5sum /usr/games/lxdoom 9aec303e660a329996e2b31ae23545c6 /usr/games/lxdoom # prelink -v /usr/games/lxdoom Assigned virtual address space slots for libraries: [...] /usr/sbin/prelink.bin: Could not prelink /usr/games/lxdoom because it doesn't use /lib/tls/i686/cmov/libc.so.6, but one of its dependencies has been prelinked against it So I guess that a previous prelink version had mistakenly changed the binary, but since I undid the prelinking the problem is fixed and will not reappear. -- Laurent Bonnaud. http://www.lis.inpg.fr/pages_perso/bonnaud/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
