From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from mailhost.nmt.edu (mailhost.nmt.edu [129.138.4.52]) by chiba.3jane.net (Postfix) with ESMTP id 7A49CABB8B for ; Sat, 5 Oct 2002 01:16:56 -0500 (CDT) Received: from a117b.rcn.NMT.EDU (a117b.rcn.nmt.edu [129.138.36.78]) by mailhost.nmt.edu (8.12.6/8.12.6) with ESMTP id g956Gsiw023696 for ; Sat, 5 Oct 2002 00:16:54 -0600 From: Quinn Harris To: gentoo-dev@gentoo.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 05 Oct 2002 00:22:15 -0600 Message-Id: <1033798935.27154.112.camel@quinn.rcn.nmt.edu> Mime-Version: 1.0 Subject: [gentoo-dev] glibc-2.3 and prelinking Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: d0ba6fa3-4567-47e2-b807-a4545fd8e4a6 X-Archives-Hash: 6466e454f5db691d1277fb8eddd1a0c1 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