Deploying Kylix Applications

Rick RossPILLAR Technology Group, Inc.


Introduction

Common Issues

Determining required libraries

How shared object libraries are located

Additional environment variables

dbExpress applications

Configuration files

Borland runtime packages

Console applications

GUI or X Window applications

Apache CGI applications

Apache DSO applications

Shared object libraries

Visibroker/CORBA applications

WebSnap applications

An example startup script

Installation applications

Tarballs

RPM

Loki Setup

Additional Resources


Introduction

This paper lays the groundwork for understanding how Linux expects applications to be installed. It looks at the various ways that shared objects are located, how to ensure environment variables are properly set, and other issues related to installing applications. Developers will be guided by providing tips and recommendations for each type of application that Kylix can generate. Finally, three tools will be discussed and demonstrated to show how to bundle up an application that is ready for deployment.

Common Issues

Regardless of the type of Kylix application that needs to be deployed, all types have several issues in common. This section will address these common issues and present solutions to solve them.

Determining required libraries

All Kylix applications, regardless of size, require additional shared libraries. Fortunately, most of the required libraries are present on most modern Linux distributions. The easiest way to determine what shared libraries an application requires is to use the ldd utility. Passing the name of an application or shared object library as a parameter to this utility will list all of the libraries that are statically linked. An example of the output of ldd is listed below.

$ ldd ./GUIHelloWorld
/lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40018000)
libqtintf.so => /opt/kylix/bin/libqtintf.so (0x4001a000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401ad000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4028d000)
libdl.so.2 => /lib/libdl.so.2 (0x402a2000)
libc.so.6 => /lib/i686/libc.so.6 (0x402a6000)
libqt.so.2 => /opt/kylix/bin/libqt.so.2 (0x403d6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40a6e000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40a7c000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40a85000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40a9c000)
libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x40abb000)
libm.so.6 => /lib/i686/libm.so.6 (0x40afd000)

Notice that the GUIHelloWorld requires fourteen shared libraries. In this example, all of the required libraries have been found. If a library cannot be located when the application is run, an error message similar to the following would appear.


$ ./GUIHelloWorld: error while loading shared libraries: libqtintf.so: cannot load shared object file: No such file or directory</P>

Now looking at the output from a “broken” GUIHelloWorld looks like this:

$ ldd ./GUIHelloWorld /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40018000) libqtintf.so => not found libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40029000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40109000) libdl.so.2 => /lib/libdl.so.2 (0x4011e000) libc.so.6 => /lib/i686/libc.so.6 (0x40122000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 

Notice the “not found” that is next to the library that ldd was unable to locate.

How shared object libraries are located

Linux has several methods that determine how shared object libraries are loaded. First, if the binary has a DT_RPATH dynamic section attribute and the DT_RUNPATH attribute does not exist, the directories specified in this section are used first. Second, all directories that are listed in the environment variable LD_LIBRARY_PATH are searched. Third, the directories specified in the DT_RUNPATH dynamic section are searched. Fourth, the program loader looks in a special cached file named /etc/ld.so.cache. This file lists directories where previous libraries have been found. It is important to note, however, that this file can be skipped. (See the man page on ld.so for more information; e.g. man ld.so). Finally, if the library has not been located after using the previous methods, the dynamic linker searches the /lib directory and the /usr/lib directory.

Note
Currently, Kylix has no method for setting either the DT_RPATH and DT_RUNPATH attributes of a executable file. Perhaps a future version of Kylix will support these attributes.

The only exception to these rules are for applications that have either the set user id or set group id bits set. These applications do not search the LD_LIBRARY_PATH environment variable, to avoid potential security risks.

With this information in mind, there are three different solutions to ensure that libraries are located.

    1. Set the LD_LIBRARY_PATH environment variable
    2. Add an entry to /etc/ld.so.conf and running ldconfig
    3. Place the libraries or a symbolic link into the /lib or /usr/lib directory.

 

Choosing an Appropriate Method

For applications that do not require special permissions, setting the LD_LIBRARY_PATH is the best solution, providing the most control over where files are located. Additionally, root privileges will not be necessary in order to install the application.

Shared object libraries and those applications that require special privileges should place a symbolic link in the /usr/lib directory that points to the installation directory of the application. Using this solution requires root privileges.

Finally, if the previous solutions are not options, add an entry to the /etc/ld.so.conf file and run the ldconfig utility which updates the system. This method also requires root permissions.

Additional environment variables

Kylix as well as most glibc functions use the LANG environment variable to determine how to display locale specific information like date and time formats, monetary and other region specific data. This environment variable should always be set to some value. If the LANG environment variable is not set, it needs to be set to an appropriate value. Also, any application specific environment variables need to be set as well.

There are three ways of setting environment variables. They are

  1. Use an application specific startup script to set the environment variable.
  2. Use an application specific configuration file to set the environment variable, like the Apache httpd.conf configuration file. This method usually requires root permissions.
  3. Set a system wide environment variable within the /etc/profile file. Also requires root permissions.

Unfortunately, there is not one universal, optimal solution since it depends on the type of application. Later, in the application specific sections, this topic is addressed once again.

dbExpress applications

DbExpress applications have additional library requirements. However, looking at the output generated by the ldd utility will not reveal which libraries the application needs, as they are loaded dynamically at runtime. For each different database an application communicates with, two additional shared libraries are needed. One library is supplied with Kylix and the other is the library supplied by the maker of the database. Two properties of the TSQLConnection component list the needed shared object libraries. Listed in the table below are the required shared object libraries needed for each database.

Database

Required Shared Libraries for DBExpress Apps

Kylix Libraries

(LibraryName Property)

Client Libraries

(VendorLib Property)

DB2

libsqldb2.so.1

libdb2.so

Interbase

libsqlib.so.1

libgds.so.0

MySQL

libsqlmy.so.1

libmysqlclient.so.6.0.0

Oracle

libsqlora.so.1

libclntsh.so.8.0

As this information is constantly changing, other versions of client libraries may work. Be sure to look at the latest information available at the Borland web site (www.borland.com/kylix/).

Applications that use a descendant of TCustomClientDataSet (e.g. TClientDataSet or TSQLClientDataSet components) or a TDataSetProvider must also include libmidas.so.1 in addition to the shared libaries listed above. This library will not appear in the output of the ldd utility, since it is loaded dynamically.

The only other file that must be deployed is the dbxres.en.1.0 resource file. It contains various resources for dbExpress applications.

Configuration files

Linux is a true multi-user platform. Most applications usually have two configuration files, a global configuration file as well as a user specific configuration file. Global configuration files are traditionally installed in the /etc directory. Other locations for global configuration files are sometimes located in the application directory or a subdirectory of the application. One important item to note is that global configuration files should be treated as read-only and should not be modified once installed. User configuration files are typically found within the user’s home directory in an application specific subdirectory. All changes to configurations should only occur within the files located in the user’s home directory.

Borland runtime packages

Packages are a shared object library with additional routines. Therefore, applications that are built with packages need to be deployed with the packages that are needed by the application. The ldd utility will list all statically linked packages that an application needs. Be sure to include all packages that are also dynamically linked.

The Borland Runtime Packages provide functionality to other packages. These dependencies are shown in the figure below.

Package Dependencies

Figure 1

The package dependencies figure is read from top to bottom. Look at the VisualDBCLX package. It requires the VisualCLX and the DataCLX package. In turn, both VisualCLX and DataCLX require the BaseCLX package. Applications that use functionality found in the VisualDBCLX package will also need to deploy the VisualCLX, DataCLX and BaseCLX packages.

Listed in the table below, are the names of the actual library files that are needed for deployment.

Package Name

BPL Library file (K1)

BPL Library file (K2)

BaseCLX

bplbaseclx.so.6.0

bplbaseclx.so.6.5

VisualCLX

bplvisualclx.so.6.0

bplvisualclx.so.6.5

DataCLX

bpldataclx.so.6.0

bpldataclx.so.6.5

NetCLX

bplnetclx.so.6.0

bplnetclx.so.6.5

VisualDBCLX

bplvisualdbclx.so.6.0

bplvisualdbclx.so.6.5

NetDataCLX

bplnetdataclx.so.6.0

bplnetdataclx.so.6.5

Indy

bplindy.so.6.0

bplindy.so.6.5

WebDBSnapCLX

n/a

bplwebdbsnapclx.so.6.5

WebSnapCLX

n/a

bplsnapclx.so.6.5

XMLRT

n/a

bplxmlrt.so.6.5

In the next table, each unit is listed that can be used within an application. For each unit, one column lists any shared object libraries that are specifically mentioned. The other column lists which package the unit is contained.

Unit

Shared Object Libraries

Located in Package(s)

AdaptReq

  

ApacheApp

  

ApacheHTTP

  

AutoAdap

  

AutoAdapSM

  

AutoDisp

  

BindHelp

 

VisualCLX

BrkrConst

 

NetCLX

CGIApp

  

CGIHTTP

  

Classes

libpthread.so.0

BaseCLX

CompProd

  

Contnrs

 

BaseCLX

ConvUtils

 

BaseCLX

CopyPrsr

 

NetCLX

CORBA

  

CorbConst

  

CosNaming

  

DateUtils

 

BaseCLX

DB

 

DataCLX

DBAdapt

  

DBAdaptimg

  

DBClient

 

DataCLX

DBCommon

 

DataCLX

DBConnAdmin

 

DataCLX

DBConsts

 

DataCLX

DBLocal

 

DataCLX

DBLocalS

 

DataCLX

DBWeb

 

NetDataCLX

DBXpress

 

DataCLX

DBXpressWeb

 

NetDataCLX

DirSel

 

VisualCLX

DSIntf

libmidas.so.1

DataCLX

DSProd

 

NetDataCLX

EncDecd

  

FMTBcd

 

DataCLX

HelpIntfs

 

BaseCLX

HTTPApp

 

NetCLX

HTTPD

libhttpd.so

 

HTTPParse

  

HTTPProd

 

NetCLX

HTTPSOAPToPasBind

  

ibmxmldom

libibmxmldom.so.1

 

IdAbout

 

Indy

IdAntiFreeze

 

Indy

IdAntiFreezeBase

 

Indy

IdBaseComponent

 

Indy

IdChargenServer

 

Indy

IdCoder

 

Indy

IdCoder3To4

 

Indy

IdCoderIMF

 

Indy

IdCoderMessageDigest

 

Indy

IdCoderText

 

Indy

IdComponent

 

Indy

IdDateTimeStamp

 

Indy

IdDayTime

 

Indy

IdDayTimeServer

 

Indy

IdDICTServer

 

Indy

IdDiscardServer

 

Indy

IdDNSResolver

 

Indy

IdDsnBaseCmpEdt

 

Indy

IdDsnPropEdBinding

 

Indy

IdDsnRegister

 

Indy

IdEcho

 

Indy

IdEchoServer

 

Indy

IdEMailAddress

 

Indy

IdException

 

Indy

IdFinger

 

Indy

IdFingerServer

 

Indy

IdFTP

 

Indy

IdGlobal

 

Indy

IdGopher

 

Indy

IdGopherConsts

 

Indy

IdGopherServer

 

Indy

IdHeaderCoder

 

Indy

IdHeaderList

 

Indy

IdHostnameServer

 

Indy

IdHTTP

 

Indy

IdHTTPServer

 

Indy

IdIcmpClient

 

Indy

IdIMAP4Server

 

Indy

IdIntercept

 

Indy

IdIPWatch

 

Indy

IdIrcServer

 

Indy

IdLogBase

 

Indy

IdLogDebug

 

Indy

IdMappedPortTCP

 

Indy

IdMessage

 

Indy

IdMessageClient

 

Indy

IdMIMETypes

 

Indy

IdNetworkCalculator

 

Indy

IdNNTP

 

Indy

IdNNTPServer

 

Indy

IdPOP3

 

Indy

IdQotd

 

Indy

IdQotdServer

 

Indy

IdRawBase

 

Indy

IdRawClient

 

Indy

IdRawFunctions

 

Indy

IdRawHeaders

 

Indy

IdResourceStrings

 

Indy

IdSimpleServer

 

Indy

IdSMTP

 

Indy

IdSNTP

 

Indy

IdSocketHandle

 

Indy

IdSocks

 

Indy

IdSSLIntercept

 

Indy

IdStack

 

Indy

IdStackConsts

 

Indy

IdStackLinux

 

Indy

IdTCPClient

 

Indy

IdTCPConnection

 

Indy

IdTCPServer

 

Indy

IdTelnet

 

Indy

IdTelnetServer

 

Indy

IdThread

 

Indy

IdThreadMgr

 

Indy

IdThreadMgrDefault

 

Indy

IdThreadMgrPool

 

Indy

IdTime

 

Indy

IdTimeServer

 

Indy

IdTrivialFTP

 

Indy

IdTrivialFTPBase

 

Indy

IdTrivialFTPServer

 

Indy

IdTunnelCommon

 

Indy

IdTunnelMaster

 

Indy

IdTunnelSlave

 

Indy

IdUDPBase

 

Indy

IdUDPClient

 

Indy

IdUDPServer

 

Indy

IdURI

 

Indy

IdVCard

 

Indy

IdWhois

 

Indy

IdWhoIsServer

 

Indy

IniFiles

 

BaseCLX

IntfInfo

  

InvConst

  

Invoker

  

InvokeRegistry

  

InvRules

  

JSPas

libjs.borland.so

 

JSPasIntf

  

JSPasObj

  

JSTypes

  

KernelDefs

 

BaseCLX

KernelIoctl

 

BaseCLX

Libc

libBrokenLocale.so.1

libc.so.6

libcrypt.so.1

libdl.so.2

libm.so.6

libnsl.so.1

libnss_compat.so.2

libnss_dns.so.2

libnss_files.so.2

libnss_hesiod.so.2

libnss_ldap.so.2

libnss_nisplus.so.2

libnss_nis.so.2

libpthread.so.0

libresolv.so.2

librt.so.1

libthread_db.so.1

libutil.so.1

BaseCLX

LibcArpa

libresolv.so.2

BaseCLX

LibElf

  

LibcRpc

libc.so.6

BaseCLX

LibcRpcSvc

libnsl.so.1

librpcsvc.so.1

BaseCLX

Masks

 

BaseCLX

MaskUtils

 

BaseCLX

Math

 

BaseCLX

Midas

 

DataCLX

MidComp

  

MidConst

 

DataCLX

MidItems

  

MidProd

  

OPConvert

  

OPToSOAPDomConv

  

OPToSOAPDomCustom

  

OrbPas40

liborbpas45.so.1

libvport_r.so

liborb_r.so

 

oxmldom

  

PagItems

  

Provider

 

DataCLX

Qt

libqtintf-6.5-qt2.3.so

libqt.so.2

VisualCLX

QActnList

 

VisualCLX

QButtons

 

VisualCLX

QCheckLst

 

VisualCLX

QClipbrd

 

VisualCLX

QComCtrls

 

VisualCLX

QConsts

 

VisualCLX

QControls

 

VisualCLX

QDBActns

 

VisualDBCLX

QDBConsts

  

QDBCtrls

 

VisualDBCLX

QDBGrids

 

VisualDBCLX

QDBLogDlg

  

QDBPWDlg

  

QDialogs

 

VisualCLX

QExtCtrls

 

VisualCLX

QForms

libpthread.so.0

VisualCLX

QGraphics

 

VisualCLX

QGrids

 

VisualCLX

QImgList

 

VisualCLX

QMask

 

VisualCLX

QMenus

 

VisualCLX

QPrinters

 

VisualCLX

QSearch

 

VisualCLX

QStdActns

 

VisualCLX

QStdCtrls

 

VisualCLX

QStyle

 

VisualCLX

QTypes

 

VisualCLX

ReqFiles

  

ReqMulti

  

Rio

  

RTLConsts

 

BaseCLX

ScriptMgr

  

SessColn

  

ShareExcept

libborunwind.so.6

 

SiteComp

  

SiteConst

  

SiteProd

  

SOAPConn

  

SOAPConst

  

SOAPDm

  

SOAPDomConv

  

SOAPEnv

  

SOAPHTTPClient

  

SOAPHTTPDisp

  

SOAPHTTPPasInv

  

SOAPHTTPTrans

  

SOAPLinked

  

SOAPMidas

  

SOAPPasInv

  

SOAPPropConv

  

SOAPPropHttp

  

Sockets

  

SqlConst

 

DataCLX

SqlExpr

 

DataCLX

SqlTimSt

 

DataCLX

StdConvs

 

BaseCLX

StrUtils

  

SyncObjs

 

BaseCLX

SysConst

 

BaseCLX

SysInit

libc.so.6

libdl.so.2

libpthread.so.0

BaseCLX

VisualCLX

DataCLX

NetCLX

Indy

VisualDBCLX

NetDataCLX

System

libborunwind.so.6

libc.so.6

libdl.so.2

libpthread.so.0

libefence.so*

BaseCLX

SysUtils

libc.so.6

libdl.so.2

libpthread.so.0

libcrypt.so.1

libm.so.6

libresolv.so.2

librt.so.1

libutil.so.1

libuuid.so.1

BaseCLX

Types

 

BaseCLX

TypInfo

 

BaseCLX

VarCmplx

 

BaseCLX

VarConv

 

BaseCLX

Variants

 

BaseCLX

VarUtils

 

BaseCLX

WbmConst

  

WebAdapt

  

WebAuto

  

WebAutoSM

  

WebBroker

  

WebBrokerSOAP

  

WebCntxt

  

WebComp

 

NetCLX

WebConst

 

NetCLX

WebContnrs

  

WebDisp

  

WebFact

  

WebForm

  

WebModu

  

WebNode

  

WebReq

  

WebScript

  

WebScriptSM

  

WebServExp

  

WebSess

  

WebUsers

  

WSDLBind

  

WSDLIntf

  

WSDLItems

  

WSDLNode

  

WSDLPub

  

WSDLSOAP

  

xdom

  

Xlib

libX11.so.6

BaseCLX

XMLBrokr

  

XMLDoc

  

xmldom

  

XMLIntf

  
*The libefence.so shared library is only used when System.pas has been compiled with the symbol EFENCE defined.

One final note about the table above. It only shows those libraries that are declared within it. Or, to say it another way, just because a unit does not reference a specific shared object library, it may still need the library through its dependencies upon other units.

Console applications

A console application is an application that does not need an X Window system to be present. Therefore, console applications should avoid using any unit that begins with the letter “Q”, the Xlib unit or the Xpm unit.

For console applications requiring environment variables, an application specific startup script should be used. In a later section, an example of a startup script will be shown.

GUI or X Window applications

At a minimum, graphical applications require the libqtintf.so shared library to be deployed along with the application. Currently, Borland only supports the libqt.2.2.4 version that is installed with Kylix. However, later versions of libqt should work, provided that they have been compiled with gcc version 2.96 or higher.

For graphical applications requiring environment variables, an application specific startup script should be used. An example is shown later in this paper.

Apache CGI applications

Since CGI applications are simply console applications, the same rules as console applications apply. Therefore, CGI applications should avoid using any unit that begins with the letter “Q”, the Xlib unit or the Xpm unit. Do not count on an X Window server being installed on a server configured with Apache.

CGI applications that require environment variables must be set within the httpd.conf file. The SetEnv directive provides the means to expose environment variables to CGI applications.

For CGI applications that are not being deployed to the standard cgi-bin directory located below the document root (which is specified with the DocumentRoot directive), add an additional section to the httpd.conf file. It should look similar to the example below.

ScriptAlias /mycgi/ “directory of cgi application”
<Directory “directory of cgi application”>
AllowOverride None
Options ExecCGI
Order allow, deny
Allow from all
</Directory>

 

dbExpress CGI applications must specify the LD_LIBRARY_PATH environment variable in the httpd.conf file. Also, the LANG environment variable must be set to an appropriate value within the httpd.conf file as well. Specifying the location of the database configuration files, the HOME environment variable should be set to the directory that contains the .borland subdirectory. If a HOME directory is not set, the global configuration file located in /usr/local/etc will be used.

Apache DSO applications

As mentioned previously, production Apache systems typically do not have an X Window system installed. Therefore, DSO applications should avoid using any unit that begins with the letter “Q”, the Xlib unit or the Xpm unit.

Two choices are available for setting environment variables in DSO applications. One option is to modify the /usr/sbin/apachectl (or /etc/init.d/httpd) script and add the appropriate environment variables. The other option is to modify the global configuration file named /etc/profile, adding the necessary environment variables. Either option requires root permissions.

Additional entries to the httpd.conf file are required for DSO applications. A LoadModule directive specifies the module name and the location of the DSO. In addition, a location directive indicates the path to activate the DSO application. A portion of the httpd.conf file is shown below.

LoadModule MyDSOApp_module <directory>/<name of library> 

<Location “URL to activate DSO, e.g. /MyFirstDSO”>
SetHandler “name of library – all lowercase”-handler
</Location>

There is one additional requirement for DSO applications that use dbExpress components. The LANG and HOME environment variables need to be set in a manner mentioned in the previous section.

Shared object libraries

Shared object libraries that use the ShareExcept unit must deploy the libborunwind.so.6 along with the standard deployment libraries.

Visibroker/CORBA Applications

CORBA applications can be either console or GUI, so they follow the same rules as normal applications. In addition, three additional shared object libraries must be deployed. They are: liborbpas45.so.1, libvport_r.so and liborb_r.so.

WebSnap Applications

Since WebSnap applications are specialized CGI or DSO applications, they follow the same rules as CGI/DSO applications. Additionally, WebSnap applications must also deploy libjs.borland.so

An example startup script

A bash script provides more flexibility for applications that need to ensure that libraries can be located when the application is loaded. An example script is shown below. Remember to substitute the appropriate installation directory and executable name

#!/bin/bash
# sample installation startup script

# Change the next two variables to specify where the application
# resides. 
app_install_dir=<location of installation directory> 
app_path=$app_install_dir/bin/<name of executable>
app_ld_path=$app_install_dir/lib

# First check to see if we have an LD_LIBRARY_PATH environment variable
if [ -n "$LD_LIBRARY_PATH" ]; then
# we do, so prepend our path first
  export LD_LIBRARY_PATH="$app_ld_path:$LD_LIBRARY_PATH"
else
# we do not, so we will create the env var.
  export LD_LIBRARY_PATH="$app_ld_path"
fi

# make sure we have something specified for the LANG environment variable
if [ -z "$LANG" ]; then
# set LANG to an appropriate value
  export LANG=en_US
fi

# now run the application, passing any parameters that where specified.
$app_path $*

 

In this example script, the binary file is expected to be located in the bin directory. Similarly, the libraries are expected to be located in the lib directory. Remember to mark the script as an executable with the chmod command.

chmod a+x mystartscript.sh

Installation applications

A number of installation utilities are available for installing applications in Linux. There are command line utilities as well as graphical utilities. Some utilities are designed for specific Linux distributions that use the RPM (Red Hat Package Manager) database and other utilities use a different method. This section will explain three popular methods.

Tarballs

A Tarball is a fancy name for a collection of files. The prefix tar is an acronym for tape archive. Originally, tar was used to create one big file from a bunch of files and then write the tar file to the tape drive. Tarballs are the most widely used distribution method for installing software on the Linux and other Unix based platforms. Creating a tarball is easily performed using the tar command line utility that comes with every Linux distribution.

The convention for creating tarballs is for all of the files that are combined that they are placed in a properly named subdirectory. Suppose that a tarball needs to be created for an application named MyAwesomeApp. An example directory structure might look like this:

<Working Dir>/
  MyAwesomeApp.1.0/
    bin/
    lib/
    man/

Creating a tarball using this directory structure is easily accomplished using the following command in the working directory.

tar cvf <name of tarfile> MyAwesomeApp.1.0/

The above command produces a tarball in the working directory. Tar files typically are named with an extension of “.tar” by convention.

Tarballs, by default, are not compressed. In order to reduce download times, they are frequently compressed. Compressed tarballs have an extension of “.gz” appended to the name. Create a compressed tarball by adding the letter “z” to the command. Compressing the MyAwesomeApp tarball would be accomplished using the following command:

tar cvzf <name of tarfile> MyAwesomeApp.1.0/

Extracting files from a tarball is accomplished using a different command. Use the following command to extract files from an uncompressed tarball.

tar xvf <name of tarfile>

Tarballs that are compressed can be extracted using the following command.

tar xvzf <name of tarfile>

To examine files in a tarball, use the following command.

tar tf <name of tarfile>

Tarballs are easy to create and distribute, however, they do have some limitations. The biggest limitation is that there is no way for a Linux distribution to know what software is installed. This makes removing software from a system may require manually removing files from various system directories (e.g. global configuration files in the /etc directory).

On the plus side, tarballs are great for placing everything in a single file. In addition, since almost every distribution has the tar utility installed, there is no need to provide an installation executable.

Other options do exist for manipulating tarballs. The man pages (man tar) are a good source of further information.

RPM

One of the major Linux distributors, Red Hat, needed a method for installing, updating and removing software easier. The result of their efforts is the Red Hat Package Manager (RPM). RPM is gaining popularity among Linux distributions but not all distributions use the RPM method. Other Linux distributors provide alternates for handling the same types of tasks.

The first step in creating an RPM is to take the source files needed to build the application. A spec file is read which informs RPM how to build the package. Several sections are in the spec file, one of, which provides the instructions for compiling or building the package. Another section lists instructions for installing the package.

A good resource for learning the details of RPM and how to build RPMs is found in the online book titled “Maximum RPM” and is available at: http://www.rpmdp.org/rpmbook/

There are also graphical toolkits used in creating RPMs. One is available at http://www.rusthq.com/.

Loki Setup

An open source graphical utility named Loki Setup is available for writing installation applications. It is based on XML and GTk. Borland uses a modified version of Loki Setup to install Kylix. XML files describe the particular information needed to install the application. More information is found at http://www.lokigames.com/development/setup.php3.

Commercial Application

If a commercial installation application is needed, InstallShield has a product called InstallShield Multiplatform that is written in Java. It provides the capability of deploying Linux applications as well as many other platforms. More information is found at http://www.installshield.com.

Additional Resources

Kylix 2 Development by Eric Whipple and Rick Ross, published by Wordware, ISBN # 1556227744

Additional online resources can be found at http://rick-ross.com

Leave a Reply

Your email address will not be published. Required fields are marked *