[gentoo-dev] glibc-2.3 and prelinking

[gentoo-dev] glibc-2.3 and prelinking

[Quinn Harris]

I have started to build a system with glibc-2.3 primarily to use
prelinking.  But I just realized that prelinking and portage aren't
going to get along.

The prelink tool will change binaries and shared libraries on the system
and therefor the modify time and the MD5 checksum.  I expect portage
will no longer properly unmerge these changed files.

The prelink tool can be changed to update the portage db probably by
using a wrapper script.  Or, portage could be modified to utilize
prelink to determine if the file was modified by prelink.  This is
explained in 
http://sources.redhat.com/ml/libc-alpha/2002-10/msg00089.html

What would be the best solution?


Some info about prelinking
http://dforce.sh.cvut.cz/~seli/en/linking2/


On a side note.  gcc-3.2 won't compile right with glibc-2.3.  It looks
like the gcc-3.2-branch cvs has the problem fixed. 
http://gcc.gnu.org/ml/gcc/2002-10/msg00333.html

Re: [gentoo-dev] glibc-2.3 and prelinking

[Quinn Harris]

I have a crappy but functional solution to this problem.  I changed the
portage.py code to use the prelink --verify option to get the input for
the MD5 checksum.  This probably incurres a substantial performance
hit.  In addition prelink is used to help calculate all MD5 checksums
which is pointless.  On the other hand, I essentally deleted 5 lines and
changed 1 to get it to work.  Heres the patch.

--- /usr/lib/python2.2/site-packages/portage.py 2002-09-25 20:17:44.000000000 -0600
+++ /mnt/gentoo/usr/lib/python2.2/site-packages/portage.py  2002-10-05 16:05:22.000000000 -0600
@@ -47,33 +47,28 @@
        if mtime != cached_mtime:
                list = os.listdir(path)
                dircache[path] = mtime, list
        return list

-try:
-       import fchksum
-       def perform_checksum(filename):
-               return fchksum.fmd5t(filename)
-except ImportError:
-       import md5
-       def md5_to_hex(md5sum):
-               hexform = ""
-               for ix in xrange(len(md5sum)):
-                       hexform = hexform + "%02x" % ord(md5sum[ix])
-               return(string.lower(hexform))
-
-       def perform_checksum(filename):
-               f = open(filename, 'rb')
-               blocksize=32768
+import md5
+def md5_to_hex(md5sum):
+       hexform = ""
+       for ix in xrange(len(md5sum)):
+               hexform = hexform + "%02x" % ord(md5sum[ix])
+       return(string.lower(hexform))
+
+def perform_checksum(filename):
+       f = os.popen3("/usr/sbin/prelink --verify " + filename, 'r')[1]
+       blocksize=32768
+       data = f.read(blocksize)
+       size = 0L
+       sum = md5.new()
+       while data:
+               sum.update(data)
+               size = size + len(data)
                data = f.read(blocksize)
-               size = 0L
-               sum = md5.new()
-               while data:
-                       sum.update(data)
-                       size = size + len(data)
-                       data = f.read(blocksize)
-               return (md5_to_hex(sum.digest()),size)
+       return (md5_to_hex(sum.digest()),size)

 starttime=int(time.time())

 features=[]



On Sat, 2002-10-05 at 00:22, Quinn Harris wrote:
> I have started to build a system with glibc-2.3 primarily to use
> prelinking.  But I just realized that prelinking and portage aren't
> going to get along.
> 
> The prelink tool will change binaries and shared libraries on the system
> and therefor the modify time and the MD5 checksum.  I expect portage
> will no longer properly unmerge these changed files.
> 
> The prelink tool can be changed to update the portage db probably by
> using a wrapper script.  Or, portage could be modified to utilize
> prelink to determine if the file was modified by prelink.  This is
> explained in 
> http://sources.redhat.com/ml/libc-alpha/2002-10/msg00089.html
> 
> What would be the best solution?
> 
> 
> Some info about prelinking
> http://dforce.sh.cvut.cz/~seli/en/linking2/
> 
> 
> On a side note.  gcc-3.2 won't compile right with glibc-2.3.  It looks
> like the gcc-3.2-branch cvs has the problem fixed. 
> http://gcc.gnu.org/ml/gcc/2002-10/msg00333.html
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>