TOC PREV NEXT INDEX

LynxOS User's Guide


Linux ABI Compatibility

The Linux ABI (Application Binary Interface) compatibility feature of LynxOS allows Linux binary applications to run under LynxOS. This chapter provides a detailed overview of the Linux ABI feature.

Overview

LynxOS supports executing dynamically-linked Linux binary applications on LynxOS systems as if they were native LynxOS applications. There is no need to rebuild Linux applications with LynxOS tools, or even access the source code. Linux application binaries can be installed and executed on a LynxOS machine in the same manner as they are installed and executed on a Linux system. The Linux ABI feature adds a new level of flexibility by allowing users to use both Linux and LynxOS binaries in parallel on a single LynxOS system.

Linux ABI compatibility is made possible by adding a Linux ABI Layer that includes Linux libraries. "Native" LynxOS applications (applications built for LynxOS) are unaffected by the addition of the Linux ABI Layer.

Installing the Linux ABI Layer

The Linux ABI Layer is installed from the Additional Components CD-ROM. Refer to the LynxOS Installation Guide for installation instructions.

In addition to the basic set of standard Linux shared libraries (linuxabi.tar.gz), LynuxWorks provides a more comprehensive set of standard Linux shared libraries (linuxabi_advanced.tar.gz) for users who require libraries that may not be included in the basic set. Note that this file is See the LynxOS Installation Guide for more details on installing these libraries.

Linux ABI Layer

This section provides a brief overview of the Linux ABI software layer. The following diagram shows how a Linux binary runs on LynxOS under the Linux ABI Layer:

Linux ABI Software Layer

A dynamically-linked application (built for either LynxOS or Linux), relies on the ld.so dynamic linker and loader to complete the process of linking all necessary references to shareable objects before the application is executed.

Linux application binaries are linked by ld.so into the shared libraries that compose the Linux ABI Layer. This Linux ABI layer translates Linux application shared object interface calls into calls that are binary-compatible with LynxOS kernel interfaces. Typically, implementation of standard interfaces are similar enough between Linux and LynxOS that only a simple translation (or none at all) is required before a call from a Linux application can go into the LynxOS kernel.

Interoperability with LynxOS Native Applications

The Linux ABI Layer relies on the LynxOS ld.so dynamic linker to resolve Linux application calls into shared objects using an appropriate set of Linux shared libraries. Native LynxOS applications are not affected by the Linux ABI feature in any way. LynxOS native applications continue to be linked into the LynxOS native shared libraries, and function as before.

Linux ABI Shared Libraries

The following table shows the shared libraries included in the Linux ABI Layer. The libraries are located in the same directories as they are on Linux (specified in the DT_RPATH field of the application ELF header). This allows the LynxOS ld.so dynamic linker and loader to link the Linux binary into the Linux ABI shared libraries.

Linux ABI Shared Libraries
x86 Shared Libraries
PowerPC Shared Libraries
lib/
lib/libc.so.6
lib/libcrypt.so.1 -> libcrypt-2.2.2.so
lib/liblynxpthread.so
lib/libm.so.6 -> libm-2.2.2.so
lib/libnsl.so.1 -> libnsl-2.2.2.so
lib/libpthread.so.0
lib/librt.so.1
lib/libtermcap.so.2 -> libtermcap.so.2.0.8
lib/libutil.so.1 -> libutil-2.2.2.so
lib/ld-linux.so.2 -> ../usr/lib/ld.so.1
lib/libresolv.so.2 -> libresolv-2.2.2.so
lib/libcrypt-2.2.2.so
lib/libnsl-2.2.2.so
lib/libtermcap.so.2.0.8
lib/libutil-2.2.2.so
lib/libresolv-2.2.2.so
lib/libdl.so.2 -> shlib/libdl.so
lib/libm-2.2.2.so
lib/
lib/libc.so.6
lib/libcrypt.so.1 -> libcrypt-2.2.1.so
lib/liblynxpthread.so
lib/libm.so.6 -> libm-2.2.1.so
lib/libnsl.so.1 -> libnsl-2.2.1.so
lib/libpthread.so.0
lib/librt.so.1
lib/libtermcap.so.2 -> libtermcap.so.2.0.8
lib/libutil.so.1 -> libutil-2.2.1.so
lib/ld.so.1 -> ../usr/lib/ld.so.1
lib/libdl.so.2 -> shlib/libdl.so
lib/libncurses.so.4
lib/libcrypt-2.2.1.so
lib/libm-2.2.1.so
lib/libnsl-2.2.1.so
lib/libutil-2.2.1.so
lib/libtermcap.so.2.0.8
lib/libresolv-2.2.1.so
lib/libresolv.so.2 -> libresolv-2.2.1.sousr/
usr/X11R6/
usr/X11R6/lib/
usr/X11R6/lib/libICE.so.6 -> libICE.so.6.3
usr/X11R6/lib/libSM.so.6 -> libSM.so.6.0
usr/X11R6/lib/libX11.so.6 -> libX11.so.6.2
usr/X11R6/lib/libXext.so.6 -> libXext.so.6.4
usr/X11R6/lib/libXmu.so.6 -> libXmu.so.6.2
usr/X11R6/lib/libXt.so.6 -> libXt.so.6.0
usr/X11R6/lib/libXaw.so.7 -> libXaw.so.7.0
usr/X11R6/lib/libXft.so.1 -> libXft.so.1.0
usr/X11R6/lib/libXpm.so.4 -> libXpm.so.4.11
usr/X11R6/lib/libXrender.so.1 ->    libXrender.so.1.0
usr/X11R6/lib/libICE.so.6.3
usr/X11R6/lib/libSM.so.6.0
usr/X11R6/lib/libX11.so.6.2
usr/X11R6/lib/libXext.so.6.4
usr/X11R6/lib/libXmu.so.6.2
usr/X11R6/lib/libXt.so.6.0
usr/X11R6/lib/libXaw.so.7.0
usr/X11R6/lib/libXft.so.1.0
usr/X11R6/lib/libXpm.so.4.11
usr/X11R6/lib/libXrender.so.1.0
usr/X11R6/lib/libXi.so.6 -> libXi.so.6.0
usr/X11R6/lib/libXi.so.6.0
usr/X11R6/
usr/X11R6/lib/
usr/X11R6/lib/libICE.so.6 -> libICE.so.6.3
usr/X11R6/lib/libSM.so.6 -> libSM.so.6.0
usr/X11R6/lib/libX11.so.6 -> libX11.so.6.2
usr/X11R6/lib/libXext.so.6 -> libXext.so.6.4
usr/X11R6/lib/libXmu.so.6 -> libXmu.so.6.2
usr/X11R6/lib/libXt.so.6 -> libXt.so.6.0
usr/X11R6/lib/libXaw.so.6 -> libXaw.so.6.1
usr/X11R6/lib/libX11.so.6.2
usr/X11R6/lib/libXaw.so.6.1
usr/X11R6/lib/libXaw.so.7 -> libXaw.so.7.0
usr/X11R6/lib/libXaw.so.7.0
usr/X11R6/lib/libXext.so.6.4
usr/X11R6/lib/libXmu.so.6.2usr/X11R6/lib/
   libXt.so.6.0
usr/X11R6/lib/libICE.so.6.3
usr/X11R6/lib/libSM.so.6.0
usr/X11R6/lib/libXft.so.1.0
usr/X11R6/lib/libXft.so.1 -> libXft.so.1.0
usr/X11R6/lib/libXrender.so.1.0
usr/X11R6/lib/libXrender.so.1 ->    libXrender.so.1.0
usr/lib/libstdc++-libc6.1-1.so.2 ->
   libstdc++-2-libc6.1-1-2.9.0.so
usr/lib/libutempter.so.0 ->    libutempter.so.0.5.2
usr/lib/libbz2.so.1 -> libbz2.so.1.0.0
usr/lib/libfreetype.so.6 ->    libfreetype.so.6.0.1
usr/lib/libreadline.so.4.1
usr/lib/libstdc++-libc6.2-2.so.3 ->
   libstdc++-3-libc6.2-2-2.10.0.so
usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
usr/lib/libutempter.so.0.5.2
usr/lib/libbz2.so.1.0.0
usr/lib/libfreetype.so.6.0.1
usr/lib/qt-2.3.0/
usr/lib/qt-2.3.0/lib/
usr/lib/qt-2.3.0/lib/libqt.so.2 ->    libqt.so.2.3.0
usr/lib/qt-2.3.0/lib/libqt.so.2.3.0
usr/lib/libjpeg.so.62 -> libjpeg.so.62.0.0
usr/lib/libpng.so.2 -> libpng.so.2.1.0.9
usr/lib/libz.so.1 -> libz.so.1.1.3
usr/lib/libGLU.so.1 ->    libGLU.so.1.1.030401
usr/lib/libGL.so.1 -> libGL.so.1.2.030401
usr/lib/libncurses.so.5 ->    libncurses.so.5.2
usr/lib/libncurses.so.5.2
usr/lib/libmng.so.1.0.0
usr/lib/libmng.so.1 -> libmng.so.1.0.0
usr/lib/libGL.so.1.2.030401
usr/lib/libGLU.so.1.1.030401
usr/lib/libz.so.1.1.3
usr/lib/libz.so -> libz.so.1.1.3
usr/lib/libpng.so.2.1.0.9
usr/lib/libjpeg.so.62.0.0
usr/lib/libreadline.so.4 ->    libreadline.so.4.1
usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
usr/lib/libstdc++-libc6.1-1.so.2
usr/lib/libutempter.so.0 ->    libutempter.so.0.5.2
usr/lib/libstdc++-libc6.1-2.so.3 ->
   libstdc++-3-libc6.1-2-2.10.0.so
usr/lib/libncurses.so.5 ->    libncurses.so.5.2
usr/lib/libncurses.so.5.2
usr/lib/libreadline.so.4 ->    libreadline.so.4.1
usr/lib/libreadline.so.4.1
usr/lib/libstdc++-2-libc6.1-1.1-2.9.0.so
usr/lib/libstdc++-libc6.1-1.1.so.2 ->
   libstdc++-2-libc6.1-1.1-2.9.0.so
usr/lib/libutempter.so.0.5.2
usr/lib/libreadline.so.3.0
usr/lib/libstdc++-3-libc6.1-2-2.10.0.so
usr/lib/libbz2.so.1 -> libbz2.so.1.0.0
usr/lib/libbz2.so.1.0.0
usr/lib/libjpeg.so.62
usr/lib/libpng.so.2.1.0.9
usr/lib/libpng.so.2 -> libpng.so.2.1.0.9
usr/lib/qt-2.3.1/
usr/lib/qt-2.3.1/lib/
usr/lib/qt-2.3.1/lib/libqt.so.2.3.1
usr/lib/qt-2.3.1/lib/libqt.so.2 ->    libqt.so.2.3.1
usr/lib/libz.so.1 -> libz.so.1.1.3
usr/lib/libz.so.1.1.3
usr/lib/libmng.so.0.0.9
usr/lib/libmng.so.0 -> libmng.so.0.0.9
usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
usr/lib/libstdc++-libc6.2-2.so.3 ->
   libstdc++-3-libc6.2-2-2.10.0.so
usr/lib/libfreetype.so.6.0.1
usr/lib/libfreetype.so.6 ->
   libfreetype.so.6.0.1

Adding Linux Shared Libraries to LynxOS

Additional shared libraries not included in the LynxOS Linux ABI distribution may be required in order to run certain Linux applications. For instance, the PERL library extensions are needed to run the Linux-built perl binary on LynxOS. Such additional libraries must be copied by the user from a Linux system and installed in the appropriate directory on LynxOS. The Linux shared libraries do not need to be rebuilt.

Determining Linux Application Library Dependencies

The shared libraries required by a particular Linux application can be viewed with the ldd command on a Linux system. For example, the Linux ls command requires the following libraries:

# ldd -d /bin/ls
 libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002d000)
 libc.so.6 => /lib/i686/libc.so.6 (0x40031000)
 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
# ls -l /lib/libtermcap.so.2
lrwxrwxrwx 1 root root 19 Jan 26 2002 /lib/libtermcap.so.2 ->  libtermcap.so.2.0.8

Updating Linux ABI Layer Libraries

Linux shared libraries can easily be updated to accommodate the needs of particular Linux applications. New libraries can easily be added to the system simply by copying them from Linux to the appropriate directories on a LynxOS system. Updated versions of shared libraries can also be added to the system by copying over the current shared library.

However, it is important to note that users should copy over the actual reference file, and not symbolic links to the reference file. For example, users should not copy over the file libncurses.so.5.2 and rename it libncurses.so.5. The Linux convention is to create a symbolic link linbncurses.so.5 to the updated library libncurses.so.5.2. This allows any application that calls libncurses.so.5 to access the updated shared libraries.

# cp <path>libncurses.so.5.2 /usr/lib
# cd /usr/lib
# ln -s libncurses.so.5.2 libncurses.so.5
# ls -l /usr/lib/libncurses.so.5*
total 509
lrwxrwxrwx 1 root 17 Feb 22 20:00 libncurses.so.5@ -> libncurses.so.5.2
-rwxr-xr-x 1 root 257524 Feb 19 18:05 libncurses.so.5.2*

Linux ABI Shared Libraries that Should Not Be Overwritten

User should not overwrite the following shared libraries installed from the Linux ABI distribution:

These are LynxOS-specific shared libraries that have the same names as Linux shared libraries. These LynxOS files are vital for the Linux ABI feature to function. If these LynxOS files are accidentally replaced by the Linux-based shared libraries, the Linux ABI environment will not function.

Specifying Linux ABI Shared Library Paths

The LD_LIBRARY_PATH environment variable specifies a search path for ELF shared libraries used by the ld.so dynamic linker. To ensure that ld.so locates all Linux ABI libraries required for a particular Linux application, LD_LIBRARY_PATH must include the path names to all the locations (directories) where respective Linux ABI libraries are located. LD_LIBRARY_PATH must be set up and exported before a Linux application can be executed.

Note: If the LynxOS X & Motif package is installed Before running a Linux GUI application, it is important to specify the LD_LIBRARY_PATH search paths in the correct order. Note that the LynxOS X11 shared libraries symbolic links are located in /usr/lib/, whereas Linux X11 libraries are located in /usr/XllR6/lib, Before running any Linux GUI application, it is necessary to define LD_LIBRARY_PATH in the order that path /usr/X11R6/lib precedes the path /usr/lib, so that the Linux GUI application started up with the Linux X shared libraries. Otherwise, the Linux GUI application will crash if it starts with the LynxOS X shared libraries .

When setting the LD_LIBRARY_PATH, be sure to specify the Linux library paths in correct order.

The following example shows how to set up LD_LIBRARY_PATH for the Linux telnet binary (assuming that the Linux telnet binary is installed in /linux/bin):

$ export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH
$ /linux/bin/telnet
$ export LD_LIBRARY_PATH=/lib:/usr/X11R6/lib: \
/usr/lib/qt-2.3.0:/usr/lib
$ /usr/bin/opera

Note: As defined by the ELF specification, if an application has the S_ISUID or S_ISGID bits set in its protection mode, the ld.so dynamic linker ignores the LD_LIBRARY_PATH environment variable. To run such applications, the S-bits must be removed from the protection mode and the application must be run from a root (superuser) login.

Running Linux Applications

This section discusses additional features and functions of the Linux ABI Compatibility Layer.

Linux Reference Distribution

The term "Linux Reference Distribution" is used to identify a particular version of Linux that is compatible with the Linux ABI Layer on LynxOS. The Linux Reference Distribution is composed of specific versions of these components:

The Linux Reference Distribution is used to validate and test Linux ABI Compatibility. Applications built on a supported version of the Linux Reference Distribution are supported. As of this printing, Linux applications built on the following Linux Reference Distribution are supported:

Refer to the LynxOS Release Notes for updates or changes to the supported Linux Reference Distribution.

Support for Dynamically Linked Applications

The Linux ABI implementation relies on the dynamic linker (ld.so) to resolve calls made by Linux binaries into the shared libraries that comprise the Linux ABI library. Such resolution is performed at run-time, when an application is loaded and linked by ld.so.

Note: Execution of statically linked Linux binaries is not supported by LynxOS. This, however, is a minor limitation, because most Linux binaries are dynamically linked. Unless explicitly specified via a special option to ld during compilation, all Linux binaries require further linking at run time by ld.so.

Support for Versioned Symbols

Linux binaries built on earlier releases of a supported Linux distribution should function when run on LynxOS. For example, if Red Hat 7.1 is the supported Linux reference distribution, applications built on Red Hat 6.x will run on LynxOS. This is because the LynxOS ld.so dynamic linker supports resolution of versioned symbols in a shared library.

The Linux ABI libraries (such as the libc library) contain multiple, versioned definitions of an interface entry point. These multiple definitions provide backward binary compatibility for earlier releases of Linux. A defined version of an interface corresponds to a particular version of the library, and thus to a particular release of Linux. When ld.so resolves links into a library, the version information is available with each unresolved symbol. This allows ld.so to determine the version of a symbol that the application requires. By linking into an appropriate version of symbols, ld.so ensures that there are no version-dependent discrepancies between the definition of the interfaces and the shared libraries.

Exceptions and Limitations

Certain Linux binaries are not supported by the Linux ABI Layer. The following table provides a list of features that are not supported with the Linux ABI Layer.

Exceptions and Limitations  
Exception
Comments
Statically linked applications
Linux ABI Layer supports execution of dynamically linked Linux binaries only.
Applications built in a Linux context later than the Linux reference context
Linux ABI libraries contain only version of symbols for the current reference context, and previous versions of the reference context.
Applications that make direct calls into the kernel
Linux ABI Layer relies on the ABI libraries to translate calls between Linux applications and the LynxOS kernel.
Applications that uses a feature of the Linux kernel not available in the LynxOS kernel
An example of this type of an exception is an application that uses the /proc file system.

Extracting RPMs with rpm2cpio

Linux binaries are sometimes distributed as RPM files. Because LynxOS does not support RPM, users must manually extract the contents of the RPM file on the Linux system. The Linux utility rpm2cpio extracts the contents of the RPM file, which can then be piped to cpio:

# rpm2cpio <rpm_filename> | cpio -ivd

Note: Note that because rpm2cpio is a statically-linked binary, it cannot run on the LynxOS Linux ABI Layer.

For more information on using rpm2cpio and cpio, see the respective man pages.

Example -- Running Opera

The following example provides instructions for running the Opera Web Browser on a LynxOS x86 system with the Linux ABI Layer.

Installing Linux ABI Layer

  1. On the LynxOS system, mount the Additional Components CD-ROM to an available mount point. For example,

# mount /dev/<cdrom> /mnt
Where <cdrom> is the device node of the CD-ROM drive, for example: ide.1.
  1. Install the Linux ABI Layer:

# cd /
# tar xvfz /mnt/tar_images/<num>linuxabi.tar.gz

Downloading Opera

  1. On the Linux system, download Opera from http://www.opera.com. Download the following version of the Opera Web browser:

- Operating system: Linux (x86)
- Language: English (United States)
- Version: 5.0
- Option: Qt dynamically linked
- Package: RPM for RedHat 7.1

Note: Users must download the Opera web browser built for Red Hat 7.1. Other versions of Opera built for other Linux distributions may not work correctly.

Also, be sure to download the dynamically-linked version. The statically-linked binary version of Opera will not work with the Linux ABI Layer.

  1. Download the Opera RPM file to a user's home directory: <user_dir>.

  2. Make a directory for Opera and copy the RPM to that directory.

# cd <user_dir>
# mkdir opera_demo
# cd opera_demo
  1. Use the rpm2cpio command to extract the contents of the RPM file:

# rpm2cpio ../opera-dynamic-rh71-5.0-3.i386.rpm | cpio -ivd
Refer to the rpm2cpio and cpio man pages for additional information on these commands.
The Opera binary and support files are extracted to the current directory.
  1. Create a tar archive of the extracted Opera files to transfer to the LynxOS system:

# tar cvf opera_demo.tar ./usr*
# ls -l opera_demo.tar
-rw-r--r-- 1 root root 4454400 Feb 28 10:41 opera_demo.tar
  1. Transfer the opera_demo.tar file to the LynxOS system via FTP or RCP.

  2. On the LynxOS system, extract the opera_demo.tar file:

# cd <user_dir>
# mkdir opera_demo
# cd opera_demo
# tar xvf ../opera_demo.tar
The Opera Linux Binary and support files are extracted to the current directory.

Configuring the Linux ABI Layer

  1. Set the LD_LIBRARY_PATH to include the library paths required by Opera:

- For x86,
# export LD_LIBRARY_PATH=/lib:/usr/X11R6/lib: \
/usr/lib/qt- 2.3.0/lib:/usr/lib
- For PowerPC,
# export LD_LIBRARY_PATH=/lib:/usr/X11R6/lib: \
/usr/lib/qt- 2.3.1/lib:/usr/lib

Note: It is important to specify the LD_LIBRARY_PATHS search paths in the correct order. Because LynxOS X11 libraries are located in /usr/lib/X11, and Linux X11 libraries are located in /usr/XllR6, specifying the incorrect path first can result in the Linux binary crashing. Setting the /usr/lib directory before /usr/X11R6/lib causes the LynxOS X11 libraries to be used instead of Linux libraries.

When setting the LD_LIBRARY_PATH, be sure to specify the Linux library paths correctly.

  1. Set the DISPLAY variable to display to a local X server (if X and Motif are installed), or display to a remote X server:

A) For a Local X server:
# export DISPLAY=0.0
B) For a Remote X server:
# export DISPLAY=<Xserver_IP_address>:0.0
Where <Xserver_IP_address> is the IP address of the X server. On the remote X server, enable remote X access with the xhost command:
# xhost +<LynxOS_IP_address>
Where <LynxOS_IP_address> is the IP address of the LynxOS system.
  1. On the LynxOS system, start opera:

# <user_dir>/opera_demo/usr/bin/opera

Opera Web Browser Running on LynxOS

LynuxWorks, Inc.
855 Branham Lane East
San Jose, CA 95138
http://www.lynuxworks.com
1.800.255.5969
TOC PREV NEXT INDEX