This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: Multilib and Linux.
- To: davem@redhat.com
- Subject: Re: Multilib and Linux.
- From: David Brownlee <abs@anim.dreamworks.com>
- Date: Tue, 20 Apr 1999 17:22:22 -0700 (PDT)
- cc: weejock@ferret.lmh.ox.ac.uk, law@cygnus.com, hjl@lucon.org, libc-hacker@cygnus.com, egcs@egcs.cygnus.com
On Tue, 20 Apr 1999, David Miller wrote:
> Date: Tue, 20 Apr 1999 22:57:59 +0100 (GMT)
> From: Matthew Kirkwood <weejock@ferret.lmh.ox.ac.uk>
>
> On Tue, 20 Apr 1999, David Miller wrote:
>
> > I wonder how a Merced userland is going to work if we wish to
> > allow people to still compile 32-bit x86 binaries, even though
> > the instruction set is radically different between the two.
>
> Merced running i386 binaries is still stricly emulation, I believe,
> so I'd see that as cross-compilation, rather than multiple ABIs.
>
> I think it's still more of a gray area than this. The x86
> instructions will execute natively on the processor, so in this
> light using your analysis we could say that executing 32-bit Sparc
> binaries on UltraSparc cpus is emulation and that compiling such
> 32-bit Sparc binaries would be cross-compilation. :-)
(Apologies to those already aware of all this :)
I believe NetBSD/sparc64 and NetBSD/mips64 (as and when it gets
into gear) do pretty much this to handle 32 bit binaries with a
compat_netbsd32 option.
Since they handle other emulations (sunos, solaris, linux, etc)
all of the relevant the machinery is already in place.
Emulated binaries have a different syscall table, though they can
end up using pretty much the same syscalls underneath.
They also pick up files in '/emul/${emulation}/...' before '/...'.
I only have 32bit NetBSD systems here, but in the case of
compat_sunos you populate /emul/sunos/usr/lib with ld.so,
libc.so.1.9, libdl.so.1.0 and anything else you need and
everything "Just Works" :)
David/absolute
-=- "I know its not the right thing, and I know its not the good thing" -=-