This section discusses developing shared and archive libraries for HP XC applications. Building a library generally consists of two phases:
Compiling sources to objects
Assembling the objects into a library
Using the ar archive tool for archive (.a) libraries
Using the linker (possibly indirectly by means of a compiler) for shared (.so) libraries.
For sufficiently small shared objects, it is often possible to combine the two steps.
A common technique is to build the archive library first, and then build the shared library from the archive library (using the linker's -whole-archive switch).
For libraries that do not use HP-MPI, it is recommended that the sources be compiled with the standard compilers (such as gcc), just as they would be on other UNIX-like platforms.
For libraries that do use HP-MPI, it is possible to use the HP-MPI compiler utilities (such as mpicc) to compile the sources to objects. For example:
To assemble an archive library, use the ar archive tool as you would on other UNIX-like platforms. To assemble a shared library, use the linker (possibly indirectly by means of a compiler) as you would on other UNIX-like platforms.
Once the library is built, it can be used to build applications, just as other libraries are used, for both serial applications (with the standard compilers) and parallel applications (with the HP-MPI compiler utilities).
Note that for shared libraries it is necessary to use LD_LIBRARY_PATH to include the directory containing the shared library, just as you would on other UNIX-like platforms.
Designing Libraries for the CP4000 Platform |
 |
This section discusses the issues surrounding the design of libraries for CP4000 platform on the HP XC system.
A user designing a library for use on an HP XC CP4000 platform can supply a 32-bit library and/or a 64-bit library. HP recommends both, to provide flexibility and to make it easy to get the 64-bit advantages locally, but be able to take the 32-bit variant to an x86-class machine or run a 32-bit variant imported from an x86-class machine.
It is the library designer's responsibility to make sure 32-bit and 64-bit object files do not collide during the build process. This can be done by "cleaning" object files from the directories between builds, or (as is more common) maintaining separate directories for the different types of objects. Separate directories also makes it easy to maintain production versions distinct from debuggable versions.
Different compilers have different ways to select 32-bit or 64-bit compilations and links. Consult the documentation for the compiler for this information.
For released libraries, dynamic and archive, the usual custom is to have a ../lib directory that contains the libraries. This, by itself, will work if the 32-bit and 64-bit libraries have different names. However, HP recommends an alternative method. The dynamic linker, during its attempt to load libraries, will suffix candidate directories with the machine type. The HP XC system on the CP4000 platform uses i686 for 32-bit binaries and x86_64 for 64-bit binaries. HP recommends structuring directories to reflect this behavior. Therefore, if your released directory structure looks like Example 4-1 “Directory Structure”, then ensure that the LD_LIBRARY_PATH has /opt/mypackage/lib in it, which will then be able to handle both 32-bit and 64-bit binaries that have linked against libmystuff.so.
Example 4-1 Directory Structure
/opt/mypackage/include/mystuff.h
/opt/mypackage/lib/i686/libmystuff.a
/opt/mypackage/lib/i686/libmystuff.so
/opt/mypackage/lib/x86_64/libmystuff.a
/opt/mypackage/lib/x86_64/libmystuff.so |
If you have an existing paradigm using different names, HP recommends introducing links with the above names. An example of this is shown in Example 4-2.
Example 4-2 Recommended Directory Structure
/opt/mypackage/include/mystuff.h
/opt/mypackage/lib/32/libmystuff.a
/opt/mypackage/lib/32/libmystuff.so
/opt/mypackage/lib/64/libmystuff.a
/opt/mypackage/lib/64/libmystuff.so
/opt/mypackage/lib/i686 -> 32
/opt/mypackage/lib/x86_64 -> 64 |
Linking an application using the library (dynamic or archive) requires you to specify the appropriate subdirectory, depending on whether the application is 32-bit or 64-bit.
For example, to build a 32-bit application, you might enter:
<linkcommand> <32-bit> -L/opt/mypackage/lib/i686 -lmystuff |
To build a 64-bit application, you might enter:
<linkcommand> <64-bit> -L/opt/mypackage/lib/x86_64 -lmystuff |
Note that there is no shortcut as there is for the dynamic loader.
Printable version
