When you write a new application, trying to make as much of the application as possible follow the POSIX standard will generally provide the highest level of portability. If an application “tracks,” or follows the rules of, POSIX, it will compile without changes on almost every known version and clone of Un*x, and on Windows NT, OS/2 2.x, and recent versions of VMS, as well. If some system-dependent code must be written, it can be isolated and clearly marked, making it possible for the next person who ports the application to a new platform to port it much more easily. And programmers on non-POSIX-compliant platforms will probably know their platforms limitations, and know what to do to port your application to their platform.

Unfortunately, the current version of the POSIX standard is showing its age a little. To make a sufficiently powerful application, you generally need to use a more powerful standard, on which defines facilities missing in POSIX. In general, if your program compiles under System V (often referred to as SYSV) or BSD systems, it will probably compile without change under Linux. System V compatibility is enabled default in Linux, and I will show later in this article how to enable BSD compatibility. In general, the Linux libraries, combined with GCC, provide one of the easiest platforms available to port to. In fact, the greatest challenge in writing applications on Linux is to not use all the facilities available on Linux. To do so would make it difficult to port the application to other platforms, even though it would make the application easier to write originally for Linux, because many of these rich facilities are not available on other platforms. Some say that Linux is a better platform to port to than to port from.

For the future, a specification called “Spec 1170” is being written, and all operating systems will have to follow it to be called “UNIXtm”. It is more powerful that most previous un*x specifications—powerful enough that common applications will not have to violate it to get real work done and will be widely followed, as most Un*x vendors have already pledged to support it. Spec1170 is being developed by X/Open, developers of the current XPG3 specification. Linux will eventually comply with most, if not all, of Spec 1170, but the developers will not commit to it without seeing the final standard.

There are essentially three areas in Linux which cause problems porting, two of which are not avoidable, and the other of which it would be undesirable to avoid.

In most cases, it has been possible to make library functions compatible with both SYSV and BSD, but in some cases, standards simply conflict. When this happens, the POSIX behavior is chosen, if POSIX defines it. (If POSIX does not define it, the most reasonable behavior is chosen, or some other standard behavior is used.) For instance, the behavior of signals has changed from one version of unix to another.

Signals in early versions of un*x were unreliable. Whenever a signal was called, the signal handler was uninstalled, and so the first thing that most signal handlers did was reinstall themselves, leading to code like:

void sigfoo_handler(int foo) {
    signal(SIGFOO, sigfoo_handler); /* Rest of signal handler */
}

However, if another SIGFOO signal was received after the signal handler had been scheduled to run, and before signal() had been called, the default behavior for the signal would happen (perhaps it was just ignored, or perhaps the program was terminated, depending on the signal), or if the new signal was received before the signal handler has returned, the signal could be lost completely. Later, reliable signals were introduced to solve these problems, but SYSV and BSD took different routes.

BSD introduced a sigaction() function to replace the old signal() function, and then re-implemented signal() in terms of sigaction(), but changed the semantics of signal() so that a signal handler installed with the signal() function stays installed. SYSV kept the old version of signal() which uninstalls itself, and introduced a whole mess of different functions for dealing with reliable signals. POSIX uses sigaction(). Linux follows POSIX, but can provide BSD signals if the BSD environment is selected, as described below.

Terminal handling also varies, and BSD terminal handling is significantly different from SYSV and POSIX, although SYSV and POSIX terminal handling are similar enough that both interfaces are easily provided by Linux by using the same mechanism in the kernel. The SYSV scheme is known as termio, and the POSIX scheme is known as termio. The older BSD scheme is known as sgtty. When porting a BSD application, you may notice compiler warnings and errors referring to sgtty.h, TIOCGETP, TIOCSETP, TIOCFLUSH, RAW, and other similar things.

To compile applications written specifically for the BSD platform, simply compile with the -I/usr/include/bsd flag, and link the application with the -lbsd flag. This makes BSD terminal handling ioctl()'s work, and makes signal() install the reliable signals that “recent” BSD code expects.

Some code simply requires functionality that isn't defined by any standard, or at least any sufficiently popular one, and is therefore written separately for each operating system. An example of this is finding the current load average or other indication of system load. For most implementations of Un*x, this requires that a process have superuser powers, and that it go looking in special places in kernel memory for magic numbers. Exactly where to look in the kernel memory (usually /dev/kmem) is determined by the derivation of the source code—SYSV code looks in one place, and BSD code looks in another. On other operating systems, many various methods are used.

In Linux, the load average can be obtained by any process by simply reading the file /proc/loadavg--you can see it yourself at the command line by typing cat /proc/loadavg. Fortunately, this and many other special features like it are standard across all installations of Linux and fairly easy to use.

Unfortunately, there are a few problems you may run into that are not quite as tractable. The formats of some files, such as /etc/utmp, are not all well-defined under Linux. That is to say, standards do exist, but they appear to be interpreted differently on different platforms. This situation will hopefully improve over time, but right now, it appears to be difficult to write code which works on all Linux installations.

For now, I recommend having a reasonably standard Linux distribution yourself, and making your software work on your own computer, and then ask that users who have problems using your software contact you. Work it out for each individual case when they do, perhaps using #ifdef's, so that when you release a new copy of your software, it will work on more Linux installations. It will also allow your software to work on more non-Linux platforms. I also suggest getting the Linux Documentation Project man pages, which include man pages defining these formats if they did not come with your Linux distribution. Follow them in the best way you can, pointing out to the authors where and why they are not clear, and help re-write them if necessary to clarify them. With your help, these small problems can be resolved, in time.

In some cases, source code written on other operating systems makes assumptions that are true on the original operating system, but which are not true under Linux because some functionality has been fixed. An example is select(). When select() was first introduced, it was pointed out in the man page that the time parameter, which was passed to select by reference (& time), was not currently modified, but that in the future it might be modified to return the time remaining in the select. Programmers either never noticed or completely ignored this advice, and now that several operating systems, including Linux, do modify the time parameter, programs which depended on it not being modified are breaking.

As a result, at regular intervals (about once a month, I think), someone posts to the newsgroup comp.os.linux.misc, saying: “The Linux select() call is broken!” even though the Linux manual pages and the Linux GCC FAQ carefully explain the situation. Operating systems keep being improved, but one thing never changes: some people will alway refuse to read the documentation.....

Some code blindly assumes that signals like SIGBUS and SIGEMT are defined, even though there is no guarantee (under POSIX) that these signals will exist on a platform. This type of code is easily fixed—simply wrap code referring to the offending signal in #ifdef SIGNAME, so that it is only included on operating systems that define that signal. Alternately, you can re-define the signals to SIGUNUSED, by adding -DSIGFOO=SIGUNUSED to the CFLAGS line in the Makefile.

Many programmers have ignored warnings not to make any assumptions about the FILE structure, and have dereferenced members of the FILE structure at will. Ignoring for the moment the argument that the original standard I/O should have included macros or functions to access those members, this causes problems under Linux, because standard I/O under Linux is based on C++ iostream library, and therefore has completely different structure members. As an example, while porting GNU Emacs 19.xx to Linux, I found that emacs wants to know how many characters are left in the stdio buffering, and the default behavior was to look at (FILE)->_ptr - (FILE)-<_base, which don't exist under Linux. Fortunately, this was done with a macro which is defined in the Emacs source, called PENDING\_OUTPUT\_COUNT, which I was able to define in the Linux-specific file linux.h as (FILE)->\_pptr - (FILE)->\_pbase.

Also, it appears that the standard libraries of many operating systems define a symbol called sys_siglist, but do not declare it. Since it is declared in the Linux header files, you simply need to comment out any extra declaration of sys_siglist in the source for the program. This is true of several other features as well: sys_siglistis only an example.

I thought that I would find a sample program to port as an example for this column, but over a weekend, as I downloaded program after program, I was just more and more impressed with the Linux C library as program after program compiled with simple tweaks like changing the Makefile to use gcc instead of cc and changing paths to executables. I finally found a program that might give some people problems porting, an editor called Freyja.

I copied the supplied makefile.unx to Makefile, and edited the Makefile. I changed CFLAGS to -O2 to use the highest level of optimization from GCC, and typed make at the command line. GCC complained that TIOCGETP, TIOCSETP, and RAW were undefined. This means that Freyja is written with BSD in mind. There did not appear to be any #define's that I could make to change Freyja's behavior to SYSV or POSIX, either.

So, following the steps in the GCC-FAQ, I added -I/usr/include/bsd to the CFLAGS line, and -lbsd to the link line (called FXLINK in Freyja for some strange reason; it's usually called LDFLAGS), and ran make again.

That was all that was required to “port” this bsd-oriented program. I had to read the documentation to find out that I needed to call it with the arguments “-kT -s29” to tell it how to write to the screen and read from the keyboard, or that I needed to compile an equivalent change into the resource file that Freyja uses, but it was very simple.

Freyja is written by Craig A. Finseth, and is available via ftp from mail.unet.umn.edu, or if you don't have ftp access, via U.S. mail. Quoting the README:

Diskette: Send the author blank diskettes:

and a SASE or enough stamps to cover return postage plus a dollar or so (so that I can buy a diskette mailer). Or you can just send me about US\$5.00 in check, stamp, whatever and I will furnish the diskette(s) and mailer. Non-US people can send me four 1.44 MB 3 1/2" diskettes in lieu of money. (More money is always nice, but please don't feel obligated in any way.)

The address is: Craig Finseth1343 LafondSt. Paul, MN55104, USA

Help!

Here's your chance to contribute! If you have difficulties porting a general Un*x application to Linux, please either send email to johnsonm@redhat.com or send snail mail to Programming Tips, Linux Journal, P.O. Box 85867, Seattle, WA 98145-1867, with a description of how to get the program via the internet, or with a copy of the application enclosed on floppy, 150MB QIC tape, or standard DAT, and with a detailed explanation of what you have tried in your attempt to port it, and I may try it myself, especially if it looks like it will make worthwhile material for this column.