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.outwould
> > 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
> 
> 
> It isn't very hard to do this at all.  I did it as a proof-of-concept a few
> months ago:
> 
> peter_at_overcee[2:18pm]/tmp/demo-218> cat foo.c
> #include <stdio.h>
> 
> main()
> {
> #ifdef __i386__
>         printf("Platform = i386\n");
> #endif
> #ifdef __amd64__
>         printf("Platform = amd64\n");
> #endif
> }
> peter_at_overcee[2:18pm]/tmp/demo-219> ./foo_i386
> Platform = i386
> peter_at_overcee[2:19pm]/tmp/demo-220> ./foo_amd64
> Platform = amd64
> peter_at_overcee[2:19pm]/tmp/demo-221> cat foo.c
> #include <stdio.h>
> 
> main()
> {
> #ifdef __i386__
>         printf("Platform = i386\n");
> #endif
> #ifdef __amd64__
>         printf("Platform = amd64\n");
> #endif
> }
> peter_at_overcee[2:19pm]/tmp/demo-222> which cc
> /usr/bin/cc
> peter_at_overcee[2:19pm]/tmp/demo-223> cc -o foo_amd64 foo.c
> peter_at_overcee[2:19pm]/tmp/demo-224> cc -m32 -o foo_i386 foo.c
> peter_at_overcee[2:19pm]/tmp/demo-225> file foo_*
> foo_amd64: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), for
> FreeBSD 8.0 (800006), dynamically linked (uses shared libs), FreeBSD-style,
> not stripped
> foo_i386:  ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for
> FreeBSD 8.0 (800006), dynamically linked (uses shared libs), FreeBSD-style,
> not stripped
> peter_at_overcee[2:19pm]/tmp/demo-226> ./foo_i386
> Platform = i386
> peter_at_overcee[2:19pm]/tmp/demo-227> ./foo_amd64
> Platform = amd64
> peter_at_overcee[2:19pm]/tmp/demo-228> uname -m
> amd64
> 
> What I did was a half-dozen lines of a hack to our bmake glue for gcc.  It
> is a hack though because I did it as specs overrides rather than have it
> figure the correct #include paths.  This means my version doesn't interact
> with -nostdinc mode correctly.  Doing it to correctly handle the paths isn't
> much harder.
> 
> -Peter

what Apple has is one file, that will run the appropiate binary if run
on an i386 or a ppc, not 2 different files - universal binary - not rosetta.

[macbook:system/danny/tmp] danny% uname -p
i386
[macbook:system/danny/tmp] danny% gcc -arch i386 foo.c -o foo_i386
[macbook:system/danny/tmp] danny% gcc -arch ppc foo.c -o foo_ppc
[macbook:system/danny/tmp] danny% lipo -create -arch ppc foo_ppc -arch i386 foo_i386 -output foo
[macbook:system/danny/tmp] danny% file foo
foo: Mach-O universal binary with 2 architectures
foo (for architecture ppc7400): Mach-O executable ppc
foo (for architecture i386):    Mach-O executable i386
[macbook:system/danny/tmp] danny% ./foo
Platform = i386
[macbook:system/danny/tmp] danny% ls -lsi foo
17768042 57 -rwxr-xr-x  1 danny  wheel  28972 Jan  6 09:32 foo
===================================
twister> uname -p
powerpc
twister> ./foo
Platform = ppc
twister> ls -lsi foo
17768042 57 -rwxr-xr-x  1 danny  wheel  28972 Jan  6 09:32 foo

danny