Linux ABI- Using other Unix binaries on Linux

(Editor's note)

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 patch,

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?

 
modprobe binfmt_coff 
 

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

Author's note:

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-2.4.2.0.diff where the "2.4.2" part corresponds to several different kernel versions.

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 patch file.

then:

 
make menuconfig 
 

then:

 
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 \ 
    abi-machdep \ 
    abi-cxenix \ 
    abi-ibcs \ 
    abi-sco \ 
    abi-socket \ 
    abi-solaris \ 
    abi-svr4 \ 
    abi-uw7 \ 
    abi-wyse \ 
    binfmt_coff \ 
    binfmt_xout 
do 
    insmod $M 
done 
 

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
info.

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:


----snip----

for M in \
    abi-machdep \
    abi-cxenix \
    abi-ibcs \
    abi-sco \
    abi-svr4 \
    abi-uw7 \
    binfmt_aout \
    binfmt_misc \
    binfmt_coff \
    binfmt_xout
do
    insmod $M
done

----snip----


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)

Editors Notes

See https://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
installed.
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
https://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/ttyxyz like god intended)
 

Linux and SCO Termcap Terminfo curses

You might run a SCO binary application from a Linux console and get a pretty messed up result - it's probably termcap or terminfo on the SCO side having bad information about how a Linux console should be treated.

The app could use either termcap or terminfo, or (unfortunately) it may use its own terminal configuration files or even worse be hard coded in the binary. You can tic a terminfo file from Linux to add the linux console to terminfo's database, but if the app uses termcap, that won't help.

Applications that use their own terminal configuration files include Basis BBX, RealWorld, and FilePro.

If you don't understand terminfo/termcap at all, see Termcap and Terminfo

Try:
https://www.aljex.com/bkw/sco/terminfo-lnx-on-sco Linux terminfo for for SCO
https://www.aljex.com/bkw/sco/termcap-lnx-on-sco Linux Termcap for SCO
https://www.aljex.com/bkw/sco/profile-lnx-on-sco Suggested .profile
https://www.aljex.com/bkw/sco/terminfo-sco-on-lnx SCO Terminfo for Linux
https://www.aljex.com/bkw/sco/termcap-sco-on-lnx SCO Termcap for Linux
https://www.aljex.com/bkw/sco/profile-sco-on-lnx Suggested .profile

You might also want to type "Linux emulation" into the Search box at the top of the page here.

Got something to add? Send me email.

3 comments

Have you tried Searching this site?

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.

Contact us