Date: Sat, 05 Jan 2008 09:32:28 +0200 From: Danny Braniss <danny@cs.huji.ac.il> To: Tim Kientzle <kientzle@freebsd.org> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=@FreeBSD.ORG, Peter Wemm <peter@wemm.org>, Jason Evans <jasone@freebsd.org>, freebsd-current@freebsd.org, =?ISO-8859-1?Q?rgrav?= <des@des.no>, Peter Schuller <peter.schuller@infidyne.com> Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] Message-ID: <E1JB3W9-000N7w-Ia@cs1.cs.huji.ac.il> In-Reply-To: <477EFEAB.8090807@freebsd.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <alpine.BSF.1.00.0801031305340.39341@goat.gigo.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> <e7db6d980801041342k562a3459y39003036dc1a5528@mail.gmail.com> <477EFEAB.8090807@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1JB3W9-000N7w-Ia>