Re: ELF dynamic loader name [was: sbrk(2) broken]

> 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