Deploying Kylix 3 Applications

发信人: Mars (FangQ), 信区: Programming标  题: Deploying Kylix 3 Applications[zz]发信站: 达摩BigGreen BBS (Sun Oct 13 23:48:21 2002), 站内信件 Kylix 3 ApplicationsRick Ross - PILLAR Technology Group, Inc.IntroductionCommon IssuesDetermining required librariesHow shared object libraries are locatedAdditional environment variablesdbExpress applicationsConfiguration filesBorland runtime packagesConsole applicationsGUI or X Window applicationsApache CGI applicationsApache DSO applicationsShared object librariesVisibroker/CORBA applicationsWebSnap applicationsAn example startup scriptInstallation applicationsTarballsRPMLoki SetupAdditional ResourcesIntroductionThis 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 IssuesRegardless 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 librariesAll 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. Below is a listing of running the ldd command on the Kylix 2 version as well as the Kylix 3 version.(Kylix 2)$ ldd ./GUIHelloWorld/lib/ => /lib/ (0x40018000) => /opt/kylix/bin/ (0x4001a000) => /usr/X11R6/lib/ (0x401ad000) => /lib/i686/ (0x4028d000) => /lib/ (0x402a2000) => /lib/i686/ (0x402a6000) => /opt/kylix/bin/ (0x403d6000)/lib/ => /lib/ (0x40000000) => /usr/X11R6/lib/ (0x40a6e000) => /usr/X11R6/lib/ (0x40a7c000) => /usr/X11R6/lib/ (0x40a85000) => /usr/lib/ (0x40a9c000) => /usr/lib/ (0x40abb000) => /lib/i686/ (0x40afd000)(Kylix 3)$ ldd ./GUIHelloWorld/lib/ => /lib/ (0x40018000) => /usr/X11R6/lib/ (0x40031000) => /lib/i686/ (0x4010f000) => /lib/ (0x40124000) => /lib/i686/ (0x40128000)/lib/ => /lib/ (0x40000000)There are a couple of things to notice. First, observe that the Kylix 2 version requires fourteen shared object libraries, while the Kylix 3 version appears to only require six. Second, notice that in the Kylix 3 version, there is no static dependency on the QT librarie In the examples shown above, 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.(Kylix 2)$ ./GUIHelloWorld: error while loading shared libraries: cannot load shared object  file: No such file or directory(Kylix 3)$ ./GUIHelloWorld: error while loading shared libraries: ./GUIHelloWorld: undefined symbol: initPAnsiStringsNow looking at the output from running ldd on a "broken" Kylix 2 GUIHelloWorld looks like this: (Kylix 2)$ ldd ./GUIHelloWorld/lib/ => /lib/ (0x40018000) => not => /usr/X11R6/lib/ (0x40029000) => /lib/i686/ (0x40109000) => /lib/ (0x4011e000) => /lib/i686/ (0x40122000)/lib/ => /lib/ (0x40000000)With Kylix 2 it is easy to determine that a required shared object library is not being located. Notice the "not found" that is next to the library that ldd was unable to locate. However, Kylix 3 makes things a much more difficult in regards to knowing which shared object libraries are required (at least with the Qt related libraries). Look at the ldd output below for the Kylix 3 version. (Kylix 3)$ ldd ./GUIHelloWorld/lib/ => /lib/ (0x40018000) => /usr/X11R6/lib/ (0x40031000) => /lib/i686/ (0x4010f000) => /lib/ (0x40124000) => /lib/i686/ (0x40128000)/lib/ => /lib/ (0x40000000)Notice that it looks the same as the working version! A couple of things have changed with Kylix 3. By default, the Qt libraries are loaded dynamically at run-time. Instead of looking for, Kylix 3 applications look for Borland has bundled and in the new By using, Borland can guarantee that the proper libaries are being loaded. For those who want to use existing Qt libraries (which may or may not be compatible) set the CLX_USE_LIBQT environment variable. (Don't forget to deploy, though) The environment variable option only works for Delphi applications, C++ applications must #define CLX_USE_LIBQT and recompile. How shared object libraries are locatedLinux 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/ 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 for more information; e.g. man 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. NoteCurrently, 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.Set the LD_LIBRARY_PATH environment variable Add an entry to /etc/ and running ldconfig Place the libraries or a symbolic link into the /lib or /usr/lib directory.Choosing an Appropriate MethodFor 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/ file and run the ldconfig utility which updates the system. This method also requires root permissions.Additional environment variablesKylix 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 areUse an application specific startup script to set the environment variable. Use an application specific configuration file to set the environment variable, like the Apache httpd.conf configuration file. This method usually requires root permissions. 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 applicationsDbExpress 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 Informix Interbase MySQL Oracle PostgreSQL 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 ( Applications that use a descendant of TCustomClientDataSet (e.g. TClientDataSet or TSQLClientDataSet components) or a TDataSetProvider must also include 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 filesLinux 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抯 home directory in an application specific subdirectory. All changes to configurations should only occur within the files located in the user抯 home directory.Borland runtime packagesPackages 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.Figure 1The 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 RTL (formerly BaseCLX) package. Applications that use functionality found in the VisualDBCLX package will also need to deploy the VisualCLX, DataCLX and RTL 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) BPL Library file (K3) BaseCLX / RTL VisualCLX DataCLX NetCLX VisualDBCLX NetDataCLX Indy SoapRTL n/a n/a WebDBSnapCLX n/a WebSnapCLX n/a XMLRT n/a 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   WebSnapCLX ApacheApp     ApacheHTTP     AutoAdap   WebSnapCLX AutoAdapSM   WebSnapCLX AutoDisp   NetCLX BindHelp VisualCLX BrkrConst   NetCLX CGIApp     CGIHTTP     Classes   RTL CompProd   WebDSnapCLX Contnrs   RTL ConvUtils   RTL CopyPrsr   NetCLX CORBA     CorbCnst     CosNaming     DateUtils   RTL DB   DataCLX DBAdapt   WebSnapCLX DBAdaptImg   WebSnapCLX DBClient   DataCLX DBCommon   DataCLX DBConnAdmin   DataCLX DBConsts   DataCLX DBLocal   DataCLX DBLocalS   DataCLX DBWeb   NetDataCLX DBXpress   DataCLX DBXpressWeb   NetDataCLX DirSel   VisualCLX DSIntf   DataCLX DSProd   NetDataCLX EncdDecd   SoapRTL FMTBcd   DataCLX HelpIntfs   RTL HTTPApp   NetCLX HTTPD   HTTPParse   WebSnapCLX HTTPProd   NetCLX HTTPSOAPToPasBind   SoapRTL HTTPUtil   SoapRTL IdAbout     IdAntiFreeze     IdAntiFreezeBase   Indy IdASN1Util   Indy IdAssignedNumbers   Indy IdAuthentication   Indy IdAuthenticationDigest   Indy IdAuthenticationManager   Indy IdAuthenticationNTLM   Indy IdBaseComponent   Indy IdBlockCipherIntercept   Indy IdChargenServer   Indy IdChargenUDPServer   Indy IdCoder   Indy IdCoder3to4   Indy IdCoderHeader   Indy IdCoderMIME   Indy IdCoderQuotedPrintable   Indy IdCoderUUE   Indy IdCoderXXE   Indy IdComponent   Indy IdCompressionIntercept Indy IdContainers   Indy IdCookie   Indy IdCookieManager   Indy IdCustomHTTPServer   Indy IdDateTimeStamp   Indy IdDayTime   Indy IdDayTimeServer   Indy IdDayTimeUDP   Indy IdDayTimeUDPServer   Indy IdDICTServer   Indy IdDiscardServer   Indy IdDiscardUDPServer   Indy IdDNSResolver   Indy IdEcho   Indy IdEchoServer   Indy IdEchoUDP   Indy IdEchoUDPServer   Indy IdEMailAddress   Indy IdException   Indy IdFinger   Indy IdFingerServer   Indy IdFTP   Indy IdFTPCommon   Indy IdFTPList   Indy IdFTPServer   Indy IdGlobal   Indy IdGopher   Indy IdGopherConsts   Indy IdGopherServer   Indy IdHash   Indy IdHashCRC   Indy IdHashElf   Indy IdHashMessageDigest   Indy IdHeaderList   Indy IdHL7   Indy IdHostnameServer   Indy IdHTTP   Indy IdHTTPHeaderInfo   Indy IdHTTPServer   Indy IdIcmpClient   Indy IdIdent   Indy IdIdentServer   Indy IdIMAP4   Indy IdIMAP4Server   Indy IdIntercept   Indy IdIOHandler   Indy IdIOHandlerSocket   Indy IdIOHandlerStream   Indy IdIOHandlerThrottle   Indy IdIPMCastBase   Indy IdIPMCastClient   Indy IdIPMCastServer   Indy IdIPWatch   Indy IdIRC   Indy IdIrcServer   Indy IdLogBase   Indy IdLogDebug   Indy IdLogEvent   Indy IdLogFile   Indy IdLogStream   Indy IdLPR   Indy IdMailBox   Indy IdMappedFTP   Indy IdMappedPortTCP   Indy IdMappedPortUDP   Indy IdMessage   Indy IdMessageClient   Indy IdMessageCoder   Indy IdMessageCoderMIME   Indy IdMessageCoderUUE   Indy IdMessageCoderXXE   Indy IdMessageCollection   Indy IdMIMETypes   Indy IdMultipartFormData   Indy IdNetworkCalculator   Indy IdNNTP   Indy IdNNTPServer   Indy IdNTLM   Indy IdPOP3   Indy IdPOP3Server   Indy IdQotd   Indy IdQotdServer   Indy IdQOTDUDP   Indy IdQOTDUDPServer   Indy IdRawBase   Indy IdRawClient   Indy IdRawFunctions   Indy IdRawHeaders   Indy IdRemoteCMDClient   Indy IdRemoteCMDServer   Indy IdResourceStrings   Indy IdRexec   Indy IdRexecServer   Indy IdRFCReply   Indy IdRSH   Indy IdRSHServer   Indy IdServerIOHandler   Indy IdServerIOHandlerSocket   Indy IdSimpleServer   Indy IdSMTP   Indy IdSMTPServer   Indy IdSNMP   Indy IdSNPP   Indy IdSNTP   Indy IdSocketHandle   Indy IdSocks   Indy IdSSLOpenSSL   Indy IdSSLOpenSSLHeaders   Indy IdStack   Indy IdStackConsts   Indy IdStackLinux   Indy IdStream   Indy IdStrings   Indy IdSync   Indy IdSysLog   Indy IdSysLogMessage   Indy IdSysLogServer   Indy IdTCPClient   Indy IdTCPConnection   Indy IdTCPServer   Indy IdTCPStream   Indy IdTelnet   Indy IdTelnetServer   Indy IdThread   Indy IdThreadComponent   Indy IdThreadMgr   Indy IdThreadMgrDefault   Indy IdThreadMgrPool   Indy IdThreadSafe   Indy IdTime   Indy IdTimeServer   Indy IdTimeUDP   Indy IdTimeUDPServer   Indy IdTrivialFTP   Indy IdTrivialFTPBase   Indy IdTrivialFTPServer   Indy IdTunnelCommon   Indy IdTunnelMaster   Indy IdTunnelSlave   Indy IdUDPBase   Indy IdUDPClient   Indy IdUDPServer   Indy IdURI   Indy IdUserAccounts   Indy IdVCard   Indy IdWhois   Indy IdWhoIsServer   Indy IndySockTransport   Indy IniFiles   RTL IntfInfo   SoapRTL InvConst   SoapRTL Invoker   SoapRTL InvokeRegistry   SoapRTL InvRules   SoapRTL JSPas WebSnapCLX JSPasIntf   WebSnapCLX JSPasObj   WebSnapCLX JSTypes   WebSnapCLX KernelDefs   RTL KernelIoctl   RTL Libc LibcArpa RTL LibcElf     LibcRpc   RTL LibcRpcSvc RTL Masks   RTL MaskUtils   RTL Math   RTL Midas   DataCLX MidComp   WebDSnapCLX MidConst DataCLX MidItems   WebDSnapCLX MidProd   WebDSnapCLX OPConvert   SoapRTL OPToSOAPDomConv   SoapRTL OPToSOAPDomCustom   SoapRTL OrbPas40   oxmldom   XMLRTL PagItems   WebDSnapCLX Provider   DataCLX QActnList   VisualCLX QButtons   VisualCLX QCheckLst   VisualCLX QClipbrd   VisualCLX QComCtrls   VisualCLX QConsts   VisualCLX QControls   VisualCLX QDBActns   VisualDBCLX QDBConsts   VisualDBCLX QDBCtrls   VisualDBCLX QDBGrids   VisualDBCLX QDBLogDlg   VisualDBCLX QDBPWDlg   VisualDBCLX QDialogs   VisualCLX QExtCtrls   VisualCLX QFileCtrls   VisualCLX QFileDialog   VisualCLX QForms VisualCLX QGraphics   VisualCLX QGrids   VisualCLX QImgList   VisualCLX QMask   VisualCLX QMenus   VisualCLX QPrinters   VisualCLX QSearch   VisualCLX QStdActns   VisualCLX QStdCtrls   VisualCLX QStyle   VisualCLX Qt   VisualCLX QTypes   VisualCLX ReqFiles   WebSnapCLX ReqMulti   WebSnapCLX Rio   SoapRTL RTLConsts   RTL ScrptMgr   WebDSnapCLX SessColn   WebSnapCLX ShareExcept   SiteComp   WebSnapCLX SiteConst   WebSnapCLX SiteProd   WebSnapCLX SOAPAttach   SoapRTL SOAPAttachIntf   SoapRTL SOAPConn   SoapRTL SOAPConst   SoapRTL SOAPDm   SoapRTL SOAPDomConv   SoapRTL SOAPEnv   SoapRTL SOAPHTTPClient   SoapRTL SOAPHTTPDisp   SoapRTL SOAPHTTPPasInv   SoapRTL SOAPHTTPTrans   SoapRTL SOAPLinked   SoapRTL SOAPMemDiag     SOAPMidas   SoapRTL SOAPPasInv   SoapRTL SockApp     SockAppHlpr     SockAppNotify     SockAppReg     Sockets   NetCLX SockHTTP     SockRequestInterpreter     SockTransport     SqlConst   DataCLX SqlExpr   DataCLX SqlTimSt   DataCLX StdConvs   RTL StrHlpr   RTL StrUtils   RTL SvrConst     SvrHTTPIndy     SvrInfoConsole     SvrInfoConst     SvrInfoModule     SvrLog     SvrLogColSettingsFrame     SvrLogDetailDlg     SvrLogDetailFrame     SvrLogFrame     SvrMainForm     SvrPropDlg     SvrSockRequest     SvrStatsFrame     SyncObjs   RTL SysConst   RTL SysInit   DataCLXIndyNetCLXNetDataCLXRTLSoapRTLVisualCLXVisualDBCLXWebDSnapCLXWebSnapCLXXMLRTL System RTL SysUtils RTL Types   RTL TypeTrans   SoapRTL TypInfo   RTL VarCmplx   RTL VarConv   RTL VarHlpr   RTL Variants   RTL VarUtils   RTL WbmConst   WebDSnapCLX WebAdapt   WebSnapCLX WebAppDbgAbout     WebAuto   WebSnapCLX WebAutoSM   WebSnapCLX WebBroker     WebBrokerSOAP   SoapRTL WebCntxt   NetCLX WebComp   WebDSnapCLX WebConst   NetCLX WebContnrs   WebSnapCLX WebDisp   WebSnapCLX WebFact   WebSnapCLX WebForm   WebSnapCLX WebModu   WebSnapCLX WebNode   SoapRTL WebReq     WebScript   WebSnapCLX WebScriptSM   WebSnapCLX WebServExp   SoapRTL WebSess   WebSnapCLX WebUsers   WebSnapCLX WSDLBind   SoapRTL WSDLIntf   SoapRTL WSDLItems   SoapRTL WSDLNode   SoapRTL WSDLPub   SoapRTL WSDLSOAP   SoapRTL xdom   XMLRTL xercesxmldom XMLRTL Xlib RTL XMLBrokr   WebDSnapCLX XMLConst   XMLRTL XMLDataToSchema   XMLRTL XMLDoc   XMLRTL xmldom   XMLRTL XMLIntf   XMLRTL XMLSchema   XMLRTL XMLSchemaTags   XMLRTL xmlutil     Xmlxform   WebDSnapCLX Xpm WebDSnapCLX XSBuiltIns   RTL XSLProd   SoapRTL ZLib WebSnapCLX ZLibConst   RTL 1, and are the Qt libraries that are loaded dynamically. Either is loaded or both and are loaded. 2 The 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 applicationsA 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 applicationsAt a minimum, graphical applications require the shared library to be deployed along with the application. Currently, Borland only supports the libqt.2.3.0 version (for Kylix 2, libqt.2.2.4) 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 and the CLX_USE_LIBQT environment variable is set. For graphical applications requiring environment variables, an application specific startup script should be used. An example is shown later in this paper. Apache CGI applicationsSince 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"  AllowOverride None  Options ExecCGI  Order allow, deny  Allow from all 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 applicationsAs 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 /  SetHandler "name of library - all lowercase"-handlerThere 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 librariesShared object libraries that use the ShareExcept unit must deploy the along with the standard deployment libraries.Visibroker/CORBA ApplicationsCORBA 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:, and ApplicationsSince 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.soAn example startup scriptA 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= app_path=$app_install_dir/bin/app_ld_path=$app_install_dir/lib# VisualCLX Script tips# ---------------# Deploying # Then make sure the following exists in app_ld_path:# and a soft link exists (in app_ld_path) to the above file # using the following command:#   ln -s The other option is to deploy ( which requires# the environment variable ## export CLX_USE_LIBQT=yes## set. (Uncomment the above line). Then make sure that # is located in the app_ld_path. ## Now create a soft link to the above file using the following:#  ln -s If you will be using an existing libqt, make sure that # # exists in a directory listed in your LD_LIBRARY_PATH.## Otherwise make sure that# # is in the app_ld_path and create a link using the following#   ln -s ------------------------# First check to see if we have an LD_LIBRARY_PATH environment variableif [ -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 variableif [ -z "$LANG" ]; then# set LANG to an appropriate value  export LANG=en_USfi# 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.shDownload the above script from here. Installation applicationsA 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.TarballsA 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: /  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  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  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 Tarballs that are compressed can be extracted using the following command.tar xvzf To examine files in a tarball, use the following command. tar tf 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.RPMOne 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: are also graphical toolkits used in creating RPMs. One is available at SetupAn 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 ApplicationIf 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 ResourcesKylix 2 Development by Eric Whipple and Rick Ross, published by Wordware, ISBN # 1556227744Additional online resources can be found at Copyright 2001,2002 by Rick Ross. All Rights Reserved. All trademarks are the property of their respective owners.Last Modified: Oct 02, 2002 12:33 PM [Q]--.[FROM: Mars.bbs@bbs.Dartmou]


©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页