Macintosh: C++ Application Development

Printer-friendly version

This topic provides details about developing Objectivity/C++ applications on Macintosh platforms. You should use this appendix in conjunction with the Objectivity/C++ and Objectivity/DDL books.

If you want to learn how to use various Objectivity/C++ features, consider downloading and running some of the sample C++ applications.

Linking Applications to Objectivity/DB

You can link C++ database applications to Objectivity/DB static or shared libraries.

Libraries for Static Linking

The following table shows Objectivity/DB static runtime libraries for C++ applications.

Note: Static libraries are no longer included with the Objectivity/DB installation. If you require static libraries, contact Objectivity Customer Support.

Table 1: Objectivity/DB Static Link Libraries (On Request Only)
Library File Description
liboo.a Objectivity/DB standard library.
liboo_adm.a Objectivity/DB administration library. Add this library to your link line before liboo.a if you are using Objectivity/C++ member functions to perform recovery operations.
liboo_dbg.a Debug version of the Objectivity/DB standard library. Add this library to your link line instead of liboo.a if you want to use debug mode. This library performs more runtime checking than liboo.a.

Static Link Rules

The following table summarizes link rules for linking with the standard Objectivity/DB static runtime library.

This table uses the following convention:

installDir Objectivity/DB installation directory—by default, /Applications/Objectivity/version

 

Table 2: Static Link Rules
Architecture Link Rule
mac86_64 -m64 installDir/lib/liboo.a -lpthread -lc -lrpcsvc -ldl

Linking to Shared Libraries

The Objectivity/DB shared libraries have the .dylib extension and contain digits x.x corresponding to the current Objectivity/DB release. To link Objectivity/DB applications to the shared libraries, choose a link rule based on whether you are linking applications for development or end-user deployment.

If your application uses persistent collections or the C++ programming interface of other Objectivity products, you must add other libraries to your link line (see Linking to Additional Objectivity Products and Features).

Link Rule for Development Environments

The following table shows the C++ Macintosh shared library link rule for development environments. This table uses the following conventions:

installDir Objectivity/DB installation directory—by default, /Applications/Objectivity/version
x.x Digits corresponding to the current Objectivity/DB release

 

Table 3: Shared Library Link Rule for Development 
Architecture Link Rule
mac86_64 -m64 -LinstallDir/lib -loo.x.x -lpthread -lc -lrpcsvc -ldl

Link Rules for End-User Environments

The following table provides information for embedding the runtime shared-library search  path so that you will be able to find Objectivity/DB libraries in the installation directory at an end-user site.

Note: The options in this table should be used in addition to the options listed in Table 3 when linking applications for deployment.

This table uses the following convention:

endUserInstallDir Installation directory at an end-user site

 

Table 4: Shared Library Link Rules for Deployment 
Architecture Link Rule
mac86_64 -Wl,-rpath,endUserInstallDir

Linking to Additional Objectivity Products and Features

When you are ready to deploy your application, you should use a command such as otool -L to identify any required libraries.

If your database application uses the C++ programming interfaces of other Objectivity products, you might need to augment the link rules given in Table 3 and Table 4.

The following table shows products that require additional link lines (as well as products that are loaded automatically via the link to the Objectivity/DB shared library.) The additional link lines should be added before liboo.a or the shared Objectivity/DB library.

Note: Shared library names have the .dylib extension and may contain digits x.x corresponding to the current Objectivity/DB release.

Table 5: Objectivity Libraries 
To Use Link to
In-process lock server (IPLS) Link to the Objectivity/DB shared library. The IPLS library is loaded automatically at runtime when needed.
Objectivity/DB Active Schema for C++

-looas.x.x

Link to the Objectivity/DB shared library.

Objectivity predicate query language

Link to the Objectivity/DB shared library. The predicate query language library is loaded automatically at runtime when needed.
ooObjectQualifier to qualify objects, or predicate scans -looObjectQualification

Link to the Objectivity/DB shared library.
Parallel query feature Link to the Objectivity/DB shared library. The parallel query library is loaded automatically at runtime when needed.
Managed placement Link to the Objectivity/DB shared library.

If Your Application Uses Persistent Collections

If your application uses persistent collections, you should include the header file ooCollectionBase.h . No special linking is necessary, other than linking to the Objectivity/DB library.

Linking a Lock-Server Performance-Monitoring Program

The following table lists the libraries for linking a custom C++ program that monitors how your database applications interact with a running lock server. The information collected by such a program can help you analyze application performance (for more information, see Monitoring Lock-Server Performance).

Table 6: Linking a Lock-Server Performance-Monitoring Program
Link to Description
-loolspm.x.x.dylib Shared library

Using Makefiles

You can use a makefile to run the DDL processor and then compile and link your application with the DDL-generated header and implementation files. You can use the makefiles from the downloadable C++ sample applications as templates (see their included readme files). You can also refer to the makefiles in the samples directory in your installation hierarchy.

	installDir/samples/cxx/helloWorld

Compiler Flags

In general, you should use the same compiler flags as those used in the sample makefiles.

When using GCC, you should avoid using the -Weffc++ and -Wnon-virtual-dtor options because they will result in compiler warnings that cannot be fixed. Alternatively, you can suppress these warnings by accessing the Objectivity/DB include directory with the -isystem option.

Application Programming Issues

Signal Handling

The Objectivity/DB predefined signal handler catches the following operating-system signals: SIGINT , SIGQUIT , SIGILL , SIGABRT , SIGFPE , SIGBUS , SIGSEGV , SIGHUP , SIGTERM , SIGEMT , and SIGTRAP .

Stack Size for Multithreaded Applications

In a multithreaded application, you may need to increase the stack size for each thread that executes Objectivity/DB operations. This is because the default thread stack size on some platforms may be insufficient to accommodate an Objectivity context. A minimum of 1 megabyte is recommended.

File Descriptor Limit

When running multithreaded programs with large numbers of threads, your process may reach the file descriptor limit. When this limit is reached, Objectivity/C++ operations may fail because the process cannot obtain a file descriptor.

To eliminate such errors, you should increase the file descriptor limit. The bash and csh commands for increasing the limit are shown in the following example. If you still experience errors, you should increase the limit incrementally.

bash:

 ulimit -n 256 

csh:

limit descriptors 256
Date: 
Monday, August 20, 2012
Product: 
Objectivity/DB
Version: 
11.0