Pavel
mayb e you need iBCS, or maybe you need to patch your kernel source with
"linux-abi" and recompile, or maybe "linux-abi" is already in there and you
need to load several modules during bootup. It depends what kernel version
you have.
so what version kernel do you have?
(uname -a)
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
> so what version kernel do you have?
> (uname -a)
>
> --
> Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
OpenLinux 3.1 kernel 2.4.2
and
SuSE 7.2 kernel 2.4.7-4GB
Thanks.
Pavel
OK, both 2.4.x kernels, so no iBCS, both use linux-abi
once on each system, run this command just to see fi the vendor has possibly
included the abi patch for you and compiled the abi support in the form of
modules. (I doubt it but it's worth checking just in case)
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 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.
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, ftp
ftp.openlinux.org, cd /pub/people/hch/linux-abi (note sometimes this site
allows anonymous access, and sometimes it doesn't, highly agrevating 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 definetly
"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, 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
in "make menuconfig" go to the section "binary support for other systems"
in there hit "y" on every option except "verbose debugging"
I mean every option too, don't leave out the ones that you think you don't
need.
then:
make clean && make dep &7 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, 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, like, 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.
like: /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, linux distribution vendors need to
compile every possible driver and feature available, but 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.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
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 another option is available too, 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", 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, but 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 littel gotha's like this, but fortunately, a lot
of them are easy to figure out some sort of answer for. its' a matter of
running the app and interpreting the error messages using a little common
sense (well should be common for any unix admin)
RedHat 7.2 comes with the ABI modules (thanks in part, I think, to
some of your postings here and on Bugzilla), but I couldn't find any
description of how to load it. I was about to load the source and
start reading...
So I just wanted to say thanks for taking the time to put that
information together!
-- bill
Bill Greene
Rubicon Group Ltd.
Pavel.
I, too, am going to thank you for putting together such a complete
answer, even though I was not the originator. I haven't tried this
yet (maybe I should hold my praise <grin>...), but I was looking to do
the same (run OSR5 binaries on Linux). I was pretty much resigned to
the fact that I'll need to keep my SCO box for some time. Maybe I'll
able to get rid of my P/200 (in favor of a P4/1.7GHz) sooner than I
thought!
If I run into any real head-scratchers, I'll return and post my
solution...
Carl Sopchak
Cegis Enterprises, Inc.
http://www.cegis123.com
Brian let me reformat that post as HTML and put it at
http://pcunix.com/Linux/linuxabi.html so that other folks can find (and
read it) more easily. He also added a few notes.
>
> If I run into any real head-scratchers, I'll return and post my
> solution...
Please do. And please consider sharing at pcunix.com also: see
http://pcunix.com/publish.html
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
I _ALWAYS_ get a message that there's a 50 user limit at
openlinux.org, so I can't connect. I've tried many times, at various
times of day, and always get the message. Frustrating, indeed...
Other sources for the patch are:
ftp.tux.org/pub/kernel/people/hch/linux-abi/v2.4
ftp.nluug.nl/pub/os/Linux/system/kernel/people/hch/linux-abi/v2.4
These two sites have ".patch.bz2" files, instead of the ".diff" files
mentioned by Brian. After using "bunzip2" to expand the patch files,
they appear to be in the same format as the .diff's from sourceforge
(see below).
sourceforge.net/projects/linux-abi
This site is (apparently) where the development is being done now, but
I'm not too sure how active it is. (The "project description has not
been posted", and the project was started over a year ago!) Also, the
naming convention seems a bit different (one less number), so I don't
know if the three numbers refer to a kernel version (as Brian stated
for the openlinux.org .diff file) or a "release" of linux-abi.
Also from the sourceforge message board, "Apparently ...
Linux-ABI is now also available from ftp.kernel.org and it's
mirrors.The directory is /pub/linux/kernel/people/hch/linux-abi/v2.4
". Haven't been there (kernel.org), so I can't tell you anything
about it...
Lastly, from the sourceforge message board, [paraphrased]: DO NOT
attempt to apply the linux-abi patch to a "distribution" kernel, only
a "clean" kernel from kernel.org. Well, since I'm running Red Hat
7.1, I guess I won't try. I think I read somewhere along the way that
linux-abi is in RH 7.2. Maybe I'll check that out...
Carl
> Lastly, from the sourceforge message board, [paraphrased]: DO NOT
> attempt to apply the linux-abi patch to a "distribution" kernel, only
> a "clean" kernel from kernel.org. Well, since I'm running Red Hat
> 7.1, I guess I won't try. I think I read somewhere along the way that
> linux-abi is in RH 7.2. Maybe I'll check that out...
linux-abi 2.4.6 is in Red Hat 7.2