bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request


From: Jeroen Dekkers
Subject: Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord)
Date: Tue, 26 Mar 2002 16:11:49 +0100
User-agent: Mutt/1.3.27i

On Tue, Mar 26, 2002 at 09:58:17AM +0100, Oystein Viggen wrote:
> * [Jeroen Dekkers] 
> 
> > On Mon, Mar 25, 2002 at 09:59:14PM +0100, Farid Hajji wrote:
> >> All in all, binary compatibility is a nice thing to have.
> >
> > If it's only used for running non-free software I disagree.
> 
> I can see no other reason.  As you said, if it's free, we just recompile
> it.  Then we can remove PATH_MAX and MAXHOSTNAMELEN dependencies, too.
> 
> > The only
> > really reason I see is that you can have the same Debian packages for
> > GNU/Hurd and GNU/Linux, which would same some few GBs in the
> > archive. For this the ABI has to be completely the same which still
> > has some issues.
> 
> For complete binary compatibility, I should think you also need complete
> feature compatibility.  This means either enhancing Linux to support
> things like translators, dumbing down the Hurd, or providing fake stubs
> in the Linux libc.  None of these are very likely.

Why? POSIX programs use the glibc ABI, which is almost the same on
GNU/Linux and GNU/Hurd. Programs could use the proc filesystem and
would have dependency on procfs-linux-2.4 then.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects

Attachment: pgpKDnPF0gh56.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]