Linux ABI- Using other Unix binaries on Linux
By Brian K. white
The linux-abi linux-abi.sourceforge.net
replaces the former ibcs2 module for providing the ability to run
other Unix binaries on Linux. On the latest kernels, abi may be
provided (it is with Red Hat 7.2 for example). but still may need
updating as it is a work in progress at this time. Brian White
provided this overview of abi.
See SCO binaries under NETBSD also.
To run Sco binaries on Linux you need:
- kernel versions < 2.2.latest: insmod iBCS
- kernel versions 2.2.latest - 2.4.0: no-mans-land, there was no
working ibcs of any form, sorry, drive through.
- kernel versions 2.4.0 - 2.4.latest: linux-abi kernel
Abi started out barely working, not working for many programs,
2.4.6 is pretty good, I've had at least one program that worked
fine on the old ibcs that doesn't work on 2.4.9, or 2.4.<less
than 6> but does work on 2.4.6. Always try the latest and work
backwards from there and hopefully one of the other versions works
without having to go all the way back to 2.2 kernels and the old
ibcs. For some special cases I think even a 2.2 box and ibcs is
preferable to a new SCO box. There is really nothing wrong with
2.2, it's modern enough to still be inter-operable with the most
current Linux and bsd boxes, you can run all the latest apps, and
it has almost as much ip nat/masquerading/filtering/forwarding
capabilities, and the old ibcs worked very well. All of *my* SCO
applications ran without flaw under ibcs. so far the closest that
abi has come has been 2.4.6, in which everything works, but one
program. That's bbx3 for xenix-386, which generates error messages
on the console, but there is actually no problem other than the
printk's themselves. A small change to one file in the abi source
tree fixes that and then all of my particular apps work without any
flaws at least with my usage pattern.
Do you have abi?
Run this command just to see if the vendor has possibly included
the abi patch for you and compiled the abi support in the form of
if you get an error, then you don't already have abi support so
you will have to add it. If you get nothing, then run
lsmod | grep coff
and verify that binfmt_coff shows up in there. If lsmod shows
the module loaded, then skip to the section labeled "Using Loadable
Modules" below, otherwise, like above you do not already have abi
support and it needs to be added.
Adding ABI to the kernel
I actually felt like I should have been a bit more explicit and
more fleshed out. I either should not have gotten at all into the
topic of how to build and install a new kernel safely and without
disabling old kernels, or I should have explained somewhat more
about it. You either know or you don't, and if you don't you need a
little more explanation than I gave, and if you do then you don't
need anything I said on that subject, so barely covering the
subject is kind of useless.
But, it can't be completely avoided because it is very closely
tied to the abi patch. in the past there was a nice single ibcs
module you could load and most people didn't need to know how to
build it. But now, the abi patch is not a stand-alone object
separate from the kernel, it is a patch that must be applied to the
source, and most vendors probably don't yet include it by default.
So one needs to know how to find and install the latest kernel
sources, apply a patch, configure, compile, install, and test,
without clobbering their existing kernel in case the new one
doesn't work well. It's easy if you've done it even once or twice,
but if you've never done it it's pretty scary for most people.
Eventually it should get included into the main kernel source and
after that no one will have to apply the patch any more and all
vendors will ship it because it will be part of the base kernel
itself. If you are running a kernel with abi, maybe the simple list
of modules to load is all that is necessary for you.
For each system, install the kernel sources if they are not
installed already (look in /usr/src/linux). When /usr/src/linux has
a kernel source tree in it, cd /usr/src/linux, and ftp
ftp.openlinux.org, cd /pub/people/hch/linux-abi .
Sometimes this site allows anonymous access, and sometimes it
doesn't, highly aggravating since this is "the source" for this
patch. Just now when I tried to double check the path to the abi
patches and their filenames, it wasn't allowing anonymous access,
so the path might be a little off. It's definitely "people/hch" or
"people/~hch" but the pub might not be necessary. Also ignore the
directory named "abi-tools", it's not that one.
Get the *.diff whose name most closely matches your kernel version,
without going higher than your kernel version. Again, I can't look
at the exact filename right now, and they may change things anyway,
but they are something like linux-abi.something-18.104.22.168.diff where
the "2.4.2" part corresponds to several different kernel versions.
(Article continues after the break)
Quit out of ftp and apply the patch like this:
patch -p0 <linux-abi*.diff
while you are still sitting in /usr/src/linux along with the
In "make menuconfig" go to the section "binary support for other
systems" and hit "y" on every option except "verbose debugging" I
mean every option too, don't leave out the ones that you think you
make clean && make dep && make bzImage && make modules && make modules_install
Manually make a new directory under /boot for the new kernel,
copy /usr/src/linux/i386/boot/bzImage, /usr/src/linux/System.map,
/usr/src/linux/.config into there, and then manually edit
/etc/lilo.conf adding a new paragraph for the new kernel without
conflicting or removing the existing ones (pick a label that
doesn't conflict, ie: anything but "linux"). Run /sbin/lilo,
reboot, type the label of the new kernel at the lilo prompt, and
when the system comes up, you should be able to run SCO binaries
with various caveats: many SCO binaries are going to fail if
certain common system files are not right where they expect them,
but they do exist on your system and you just need to make a few
symlinks to satisfy the SCO binaries.
Examples: /usr/share/terminfo should have a link as
/usr/lib/terminfo, you might not be setting the TZ variable in your
profile currently, but some Sco binaries will get the date/time
wrong without it even though all your other programs are fine. You
might need to import terminfo and termcap definitions from the SCO
box, you might need to modify your existing termcap & terminfo
(as in: for the "linux" and "xterm" term types) because sometimes a
Sco binary will choke if it hits a terminal capability it doesn't
understand, or if it fails to get one it expects.
Using Loadable Modules
Another way to get the abi support is to type "m" instead of "y"
for all the abi options in "make menuconfig". If you do this, then
when you compile the kernel, the abi support gets built as a bunch
of loadable modules instead of getting built right into the kernel.
It's better for something like this to build it right in if you
need to run the binaries all the time. It's possible for loadable
modules to just stop working after a while, or fail to load one day
for some reason, etc... but, while Linux distribution vendors need
to compile every possible driver and feature available, you don't
want to (actually it's impossible) to build a kernel with every
possible option compiled in (some things are only available as
modules, some only work right as modules, and some are mutually
exclusive so you can't have both in at the same time). So vendors
compile everything as modules and you load what you need. *If* the
vendor has supplied the modules for abi, you can load them by
putting the following in /etc/rc.d/rc.local
for M in \
Brian recently updated this for 7.3:
I have a small update for the linux-abi page.
I just set up abi on our new redhat 7.3 server and there were a few
changes from the previous version. I figured I might as well relay the new
all it is is an updated insmod command for /etc/rc.d/rc.local
here is the command(s) to put in rc.local on RedHat 7.3:
for M in \
that's it. a few modules no longer exist and I added two more to the list
here, I'm not really sure how much you need the binfmt_aout and _misc if
at all strictly for abi, but they don't hurt and I've been up all night
and still need to fake being fresh and energetic for a big install today
for a new client... so I'm not testing any further right now. :)
You can run /etc/rc.d/rc.local manually the first time after
editing, no need to reboot just to load these modules. Once they
are loaded, the same caveats as above apply. Just because the
kernel can now physically run the binaries doesn't mean you are
necessarily even very close to being able to run and use the
application. There is more to a 'system' than it's kernel. When you
take a SCO binary and transplant it onto a Linux box, and then get
ibcs/abi support working in the kernel, all you've done at that
point is supplied the binary with *somewhat* of a substitute for
the kernel it expects to work with. Much of the rest of the system
is going to be good enough also simply by virtue of being a
unix-like system. but then again, there are a lot of differences
between SCO and lInux and any of these may need to be "faked"
somehow on the Linux box for the sco binary to run correctly.
Sometimes the sco binary may have a particular compiled-in
default, but it is overridable by some environment variable or
setting in it's config file. For instance, a sco binary could
easily have a built in default print command of "lp", to print, the
program will attempt to pipe something into a program named "lp",
which will fail on most Linux systems. You *could* make a symlink
from /usr/bin/lpr to /usr/bin/lp, but that is not good enough
because Sco's lp has different options than Linux's lpr. You could
make a shell script named "lp" that translated the most common
options to Linux equivalents, like changing "lp -dsomeprinter" to
"lpr -Psomeprinter". In many cases you may have an easier option
where you simply define an environment variable that the program
will check for, or use the programs config file to tell the program
that it's print command is "lpr -Psomeprinter"
There are tons of possible little gotcha's like this, but
fortunately, a lot of them are easy to figure out some sort of
answer for. It's a matter of running the application and
interpreting the error messages using a little common sense (well,
should be common for any unix admin)
See http://groups.google.com/group/comp.unix.sco.misc/browse_thread/thread/7ed0f2b47f866b2b/dc8905f03ad0ca7f also.
At another post ("Want to run Sco-unix program on Linux), Brian pointed out some things about installing SCO Unix software:
.. if the instructions say "insert floppy and run custom"
then you have to install on a sco box and tar up the files after they are
if the instructions say something along the lines of "insert the floppy and
run tar xvf /dev/install , then run sh /tmp/install.sh" then you can go to
http://www.aljex.com/bkw/filepro/ and get "scotar"
In no case I have ever seen yet does one mount install floppies. sometimes
you mount install cd's, but never floppies.
He also made some other comments:
There are a bunch of little issues you need to be aware of when running a
sco binary under linux. none of which are too bad, but there are usually
more than a few snags to work around and it means you can't expect to just
run it immediately as easily as if you were installing on sco.
shell scripts that assume /bin/sh behaves like SCO's /bin/sh, which linux's
/bin/sh does _not_ (easy fix is to install pdksh and edit the top line of
all shell scripts that came with the app)
common built-in system commands, like lp commands, need to be modified
(change "lp -dsomething -s", to "lpr -Psomething". or if you're me, write a
wrapper script that does it automatically on the fly)
If your app expects a sco-ish terminal, you'll need to adjust termcap and or terminfo (see Termcap and Terminfo Explained). Even "xterm" is different from SCO to Linux.
SCO apps may have other dependencies that may require some creative symbolic links:
modern versions of linux, with Unix98-pty's and/or devfs enabled in the
kernel will generate device names that some legacy programs simply never
counted on and can't handle. (I have an app that can't handle the fact that
`tty` spits out /dev/pts/3 instead of /dev/ttyXXX like god intended)
If this page was useful to you, please help others find it:
More Articles by Brian K. White
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.