From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 08:03:41 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 419A316A468; Sat, 5 Jan 2008 08:03:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id F17BC13C4CE; Sat, 5 Jan 2008 08:03:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1JB3W9-000N7w-Ia; Sat, 05 Jan 2008 09:32:29 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Tim Kientzle In-reply-to: <477EFEAB.8090807@freebsd.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> <477EFEAB.8090807@freebsd.org> Comments: In-reply-to Tim Kientzle message dated "Fri, 04 Jan 2008 19:51:07 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Jan 2008 09:32:28 +0200 From: Danny Braniss Message-ID: Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=@FreeBSD.ORG, Peter Wemm , Jason Evans , freebsd-current@freebsd.org, =?ISO-8859-1?Q?rgrav?= , Peter Schuller Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 08:03:41 -0000 > Peter Wemm wrote: > > > On the other hand, if ld-elf.so.1 is fairly unique in this > > > concern, it might be simpler to rename it to: > > > ld-elf-{i386,amd64,ppc,...}.so.1 > > > > While this doesn't count as an explicit vote against the rename, we can > > solve the chroot problem easily. > > Details? Does your approach also solve the problem of > sharing /usr across different architectures (either in > a diskless NFS environment or a dual-boot scenario with > a shared /usr partition)? > > > However, renaming ld-elf.so.1 is a bad idea in general. ... things like gdb > > "know" how to handle ld-elf.so.1. Getting those upstream folks to add > > additional strcmp()'s for ld-elf-i386.so.1, ld-elf-amd64.so.1 etc will > > be hard enough, and it will add another hurdle ... > > I'm not sure that I see the problem. What am I missing? > 1) gdb is built to debug binaries for a particular architecture. > (gdb/ARM can't debug gdb/i386 binaries) > 2) gdb therefore only needs to check for "ld-elf-"`uname -m`".so.1", > which is easy to handle when gdb itself is built. > > I can see some subtleties for cross-builds, but nothing > outrageous. > > It also seems that your argument applies just as well to > ld-elf.so.1 and ld-elf32.so.1. Either way, there's more > than one ld-elf.so.1, and therefore more than one name > to keep track of. > > I'm not championing the rename by any means, just trying > to better understand the issues. The fact that amd64 can > run i386 binaries but not vice-versa has a lot of subtle > implications. Also, this is the first time that FreeBSD > has really had large user bases on two fundamentally > different architectures, so it's the first time we've > really had to confront some of these support issues > (such as the shared /usr scenario). > > Tim Kientzle The main issue is NOT sharing / or /usr or /usr/local, that is peenuts. root and usr is less that 500 MGB, /usr/local though big, is handled neatly by amd (the automounter). cross building is one issue, but the real problem is sharing user's binaries. in Apple one can compile a binary for both i386 & ppc, and the binary is twice as big. side note, I compiled such a program, but by mistake chose two different binaries to be joined, and imagine my surprice when it acted differently from expected. We have come a long way since the days that a wrong architecture a.out would just coredump. In the old days, we had ~/bin/$arch in our path to keep different binaries, it was the days of VAX/Sun, but since i386 arrived, this has been forgotten. Now we are concidering to deploy amd64, and it would be nice if it can be a 2way street - amd64 can run i386, but i386 should run the i386 version ... just blaberring before coffee. danny