Re: libc strategy

[Steve Price <sprice@hiwaay.net>]

On Mon, Jul 02, 2001 at 03:25:02PM -0700, Michael Goetze wrote:
> 
> > and patching every existing package that doesn't work with glibc
> > would also be a major pain.
> 
> But here you're jumping to conclusions. The BSD libc is not some relict
> of 20 years ago, it is a living, breathing entity. And, as has been
> pointed out, pretty much all of the GNU tools already run on it without
> problems. Indeed, any program that is properly autoconf'ed should run
> on BSD with no problems. And, if it doesn't, then it'll be our job to
> ensure that it does - which should also produce goodwill in the BSD
> community, because we'd be expanding the range of applications
> available to them.

I think everyone is missing one very important fact.  All of the
BSDs can run Linux binaries that are linked with glibc already.
No need to port glibc or anything else.  It is a called the Linuxulator.

How's this for thinking outside the box?  Install FreeBSD, NetBSD,
or OpenBSD on turn on the Linuxulator.

        pkg_add -r linux
        cat 'linux_enable="YES"' >> /etc/rc.conf
        linux

Systematically replace the native BSD binaries with the Linux
equivalent.  There's no requirement that a Linux binary be in the
/compat/linux tree.  They can be anywhere really.  If you really
want to go nuts devise a patch to a BSD kernel to look for the Linux
binaries in /lib or /usr/lib and the BSD libraries in /compat/bsd.
Badaboom, badabing.  Linux userland with a BSD kernel with the
minimum amount of fuss.

Most people jump to the incorrect conclusion that the way the
Linuxulator runs Linux binaries is through emulation.  This is
absolutely false.  Check out the code sometime and you'll see why
oftentimes people claim that Linux binaries actually run faster on
BSD than on Linux.  The Linuxulator is nothing more [1] than an
alternate syscall map - a map that is used regardless of whether
the binary is a native BSD, one from Linux, BSDi, OSF/1, ...

-steve

[1] Not to trivialize what it does but this is a big part of how
    it works - provides an alternate mapping for calls into the
    kernel, tell it where to look for the libraries to link with,
    which ELF loader to use, etc.