> > > There are several layers. For example, we already use the same object
> > > format (ELF). Then, we can provide the same glibc ABI (currently we don't,
> > > though) in the future, which allows programs that only use glibc to access
> > > the system's functionality to run directly on the Hurd without emulation.
> >
> > What would be _exactly_ needed to get a dynamically linked linux app
> > run under the Hurd? I'm really curious here!
>
> Well, you could start with an objdump and compare the exposed symbols, this
> would show.
Under Linux, if we look at uname for instance, the required dynamic libs are
the following:
$ ldd `which uname`
libc.so.6 => /lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
The Hurd glibc should have the same symbols as the Linux' glibc, right? Then,
what under the Hurd /lib/ld-linux.so was just a symlink to the Hurd equivalent
(is it /lib/lib-hurd.so?) or a simple wrapper to the Hurd equivalent
function calls?
Would it be sufficient to have a "simple" Linux binary (i.e. a program that
does not used pthreads for instance) running under the Hurd? What would
happen?
Where can we find documentation about how those different layers work
together (maybe in the Linux doc)?
> One thing is libio, we will get that now (*sigh* some hard bugs in the way,
> though, difficult to debug. It works in a chroot, but not at boot time).
What is libio?
Thanks,
Ludovic.
_______________________________________________
Help-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/help-hurd
