Top: Deploying the shared (dynamic) library
Starting from version 1.7 PTypes builds two separate versions of the library: static and shared (DLL on Windows), giving you a choice, and at the same time putting into a dilemma.
Both static and dynamic linking have their advantages and disadvantages. While small applications consisting of a single executable would prefer to link the library directly, more complex projects with multiple dynamic components and executables would greatly benefit from going 'totally dynamic', including generic low-level libraries, such like CRTL and PTypes. Before making a decision, consider the following:
Advantages of static linking:
Advantages of dynamic linking:
In summary, dynamic linking is good (1) for big projects, or (2) if the library is widely used by many software vendors in its dynamic (shared) form.
PTypes 1.7 builds a shared object named libptypes.so.1 and also, by tradition, creates a symbolic link libptypes.so. Both files are placed in so/.
If you decided to link your program against PTypes shared object instead of the static library, all you'd have to do is to change the library path in your makefile from -L../ptypes/lib to -L../ptypes/so. When running the program, it will then require the shared library to be either in one of the default locations (usually /usr/lib and /usr/local/lib), or you will have to override the LD_LIBRARY_PATH environment variable and point to the directory where the shared object resides, e.g. ~/ptypes/so.
Both files, libptypes.so.1 and the symlink libptypes.so, should be deployed and installed along with your application, regardless of which name you are using. The version number '1' will change when PTypes adds a number of new features and becomes significantly bigger (e.g. if we add Unicode support). This will leave you the possibility to link against the smaller version libptypes.so.1, if you don't want to use the new one, or if you are not aware of it at all.
The PTypes MSVC project is configured so that the 'release' version of ptypes.dll along with the import library ptypes.lib is copied into so\ as the final step of the build process. Ptypes.dll does not contain any debugging information and is ready to be deployed. Note that the library itself is linked against the multithreaded DLL version of CRTL.
Starting from version 1.7.1 PTypes places a VERSION resource in the DLL, allowing the system or the setup program to automatically compare the existing ptypes.dll the user may have in the system with the one that comes with your program. This is usually done from within the installation script.
If, for some reason, you wish to check the version of the shared library you linked with dynamically, you may check the global variable __ptypes_version, which is declared in <pport.h>. This variable holds the version number encoded as a single integer, e.g. 0x010705 designates version 1.7.5. In this form the version numbers (required and actual) can be easily compared as integers.
If you need to check the version of PTypes before loading the library (for example, during the installation on Unix), you may write a program that loads the shared object and reads the global symbol __ptypes_version at run-time, using the system dynamic loading interface. Note that this program itself is not using PTypes. Some Unix systems require to link the program with -ldl.
#ifdef WIN32 # include <windows.h> #else
See also: Compiling and Porting