CSDN博客

img yuanqingfei

Deploying Kylix 3 Applications

发表于2004/9/26 10:26:00  3149人阅读

分类: 〖Delphi〗

发信人: Mars (FangQ), 信区: Programming
标  题: Deploying Kylix 3 Applications[zz]
发信站: 达摩BigGreen BBS (Sun Oct 13 23:48:21 2002), 站内信件

http://www.rick-ross.com/papers/k3/k3deploy.html

Deploying Kylix 3 Applications


Rick Ross - PILLAR 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. 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/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)

(Kylix 3)
$ ldd ./GUIHelloWorld
/lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 
(0x40018000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40031000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4010f000)
libdl.so.2 => /lib/libdl.so.2 (0x40124000)
libc.so.6 => /lib/i686/libc.so.6 (0x40128000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (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: 
libqtintf.so: cannot load shared object 
 file: No such file or directory

(Kylix 3)
$ ./GUIHelloWorld: error while loading shared libraries: 
./GUIHelloWorld: undefined symbol: initPAnsiStrings



Now looking at the output from running ldd on a "broken" 
Kylix 2 GUIHelloWorld looks like this: 

(Kylix 2)
$ 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)


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/libNoVersion.so.1 => /lib/libNoVersion.so.1 
(0x40018000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40031000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4010f000)
libdl.so.2 => /lib/libdl.so.2 (0x40124000)
libc.so.6 => /lib/i686/libc.so.6 (0x40128000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (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 libqt.so, Kylix 3 applications look for 
libborqt.so. Borland has bundled libqtintf.so and libqt.so in 
the new libborqt.so. By using libborqt.so, 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 libqtintf.so, 
though) The environment variable option only works for 
Delphi applications, C++ applications must #define 
CLX_USE_LIBQT and recompile. 
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.
Set the LD_LIBRARY_PATH environment variable 
Add an entry to /etc/ld.so.conf and running ldconfig 
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
Use 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 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 libdb2.so 
Informix libsqlinf.so libinfclient.so.1.0.0 
Interbase libsqlib.so libgds.so.0 
MySQL libsqlmy.so libmysqlclient.so.10.0.0 
Oracle libsqlora.so libclntsh.so.8.0 
PostgreSQL libsqlpg.so libpg.so 

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抯 
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 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.

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 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 bplbaseclx.so.6.0 bplbaseclx.so.6.5 
bplrtl.so.6.9 
VisualCLX bplvisualclx.so.6.0 bplvisualclx.so.6.5 
bplvisualclx.so.6.9 
DataCLX bpldataclx.so.6.0 bpldataclx.so.6.5 
bpldataclx.so.6.9 
NetCLX bplnetclx.so.6.0 bplnetclx.so.6.5 bplnetclx.so.6.9 
VisualDBCLX bplvisualdbclx.so.6.0 bplvisualdbclx.so.6.5 
bplvisualdbclx.so.6.9 
NetDataCLX bplnetdataclx.so.6.0 bplnetdataclx.so.6.5 
bplnetdataclx.so.6.9 
Indy bplindy.so.6.0 bplindy.so.6.5 bplindy.so.6.9 
SoapRTL n/a n/a bplsoaprtl.so.6.9 
WebDBSnapCLX n/a bplwebdbsnapclx.so.6.5 
bplwebdbsnapclx.so.6.9 
WebSnapCLX n/a bplsnapclx.so.6.5 bplsnapclx.so.6.9 
XMLRT n/a bplxmlrt.so.6.5 bplxmlrt.so.6.9 

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 libqt.so.21
libborqt-6.9-qt2.3.so1
libqtintf-6.9-qt2.3.so1 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 libhttpd.so   
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 libz.so.1 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 libjs.borland.so WebSnapCLX 
JSPasIntf   WebSnapCLX 
JSPasObj   WebSnapCLX 
JSTypes   WebSnapCLX 
KernelDefs   RTL 
KernelIoctl   RTL 
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
RTL 
LibcArpa libresolv.so.2 RTL 
LibcElf     
LibcRpc   RTL 
LibcRpcSvc libnsl.so.1
librpcsvc.so.1 RTL 
Masks   RTL 
MaskUtils   RTL 
Math   RTL 
Midas   DataCLX 
MidComp   WebDSnapCLX 
MidConst libmidas.so.1 DataCLX 
MidItems   WebDSnapCLX 
MidProd   WebDSnapCLX 
OPConvert   SoapRTL 
OPToSOAPDomConv   SoapRTL 
OPToSOAPDomCustom   SoapRTL 
OrbPas40 liborbpas45.so.1
libvport_r.so
liborb_r.so   
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 libpthread.so.0 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 libborunwind.so.6   
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   DataCLX
Indy
NetCLX
NetDataCLX
RTL
SoapRTL
VisualCLX
VisualDBCLX
WebDSnapCLX
WebSnapCLX
XMLRTL 
System libborunwind.so.6
libc.so.6
libdl.so.2
libpthread.so.0
libefence.so2 RTL 
SysUtils libuuid.so.1 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 libxercesxmldom.so.1 XMLRTL 
Xlib libX11.so.6 RTL 
XMLBrokr   WebDSnapCLX 
XMLConst   XMLRTL 
XMLDataToSchema   XMLRTL 
XMLDoc   XMLRTL 
xmldom   XMLRTL 
XMLIntf   XMLRTL 
XMLSchema   XMLRTL 
XMLSchemaTags   XMLRTL 
xmlutil     
Xmlxform   WebDSnapCLX 
Xpm libXpm.so.4 WebDSnapCLX 
XSBuiltIns   RTL 
XSLProd   SoapRTL 
ZLib libz.so.1 WebSnapCLX 
ZLibConst   RTL 
1 libqt.so.2, libborqt-6.9-qt2.3.so and libqtintf-6.9-qt2.3.so 
are the Qt libraries that are loaded dynamically. Either 
libborqt.so is loaded or both libqtintf.so and libqt.so are 
loaded. 
2 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.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 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"

  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 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 / 


  SetHandler "name of library - all lowercase"-handler

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= 
app_path=$app_install_dir/bin/
app_ld_path=$app_install_dir/lib

# VisualCLX Script tips
# ---------------
# Deploying libborqt.so? 
# Then make sure the following exists in app_ld_path:
#   libborqt-6.9.0-qt2.3.so
# and a soft link exists (in app_ld_path) to the above file 
# using the following command:
#   ln -s libborqt-6.9.0-qt2.3.so libborqt-6.9-qt2.3.so
#
# The other option is to deploy (libqtintf.so) which requires
# the environment variable 
#
# export CLX_USE_LIBQT=yes
#
# set. (Uncomment the above line). Then make sure that 
#   libqtintf-6.9.0-qt2.3.so
# is located in the app_ld_path. 
#
# Now create a soft link to the above file using the 
following:
#  ln -s libqtintf-6.9.0-qt2.3.so libqtintf-6.9-qt2.3.so
#
# If you will be using an existing libqt, make sure that 
#   libqt.so.2 
# exists in a directory listed in your LD_LIBRARY_PATH.
#
# Otherwise make sure that
#   libqt.so.2.3.0 
# is in the app_ld_path and create a link using the 
following
#   ln -s libqt.so.2.3.0 libqt.so.2
#
# ------------------------

# 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_PA
TH"
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
Download the above script from here. 
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: 
/
  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.
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



? 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]

--
☆ 来源:.大绿 BBS.Dartmouth.Edu.[FROM: Mars.bbs@bbs.Dartmou]
0 0

相关博文

我的热门文章

img
取 消
img