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