Developers

Windows

On Windows, we recommend using Dependency Walker to inspect dynamic library dependencies. Dependency Walker can be downloaded from dependencywalker.com. Note that this procedure is not recommended for diagnosing Omnis external components directly (DAMs for example). Omnis automatically attempts to load any Omnis external components placed inside the Omnis/xcomp folder.

Open Dependency Walker and use the File menu to open the DLL in question. This will be normally be a third-party client library or plug-in that you have downloaded and installed separately. In this example the output shown is for the SSL-enabled MySQL client library obtained from the MySQL website. The SSL-enabled PostgreSQL client library will show very similar results.

After loading the DLL, collapse the tree list in the left-hand panel to leave only the top-level dependencies, as shown. The product documentation provides an in-depth description of the various icons and their meanings. In summary however:

indicates a missing module. These can normally be ignored if they relate to delay-loaded system DLLs. System DLLs have filenames of the form: "API-MS-WIN-CRT..."

indicates a 64-bit module which was loaded successfully. If you are diagnosing a 32-bit module, the icon(s) will appear as instead.

indicates an invalid module. This normally occurs when a DLL of the wrong architecture was found instead of, or before the one you were expecting.

indicates a missing module, or a module that has one or more missing symbols. This can occur when a loading an older/out-dated version of the module, or if the module itself has a missing dynamic dependency. Expand the tree to show the missing file(s). You may need to extract further files from the third-party distribution.

All missing and invalid dependencies need to be resolved before Omnis will be able to load the parent module. You can see in the above example that the required SSLEAY32 and LIBEAY32 DLLs were found inside the Omnis folder.

 

macOS

On macOS, you can use the otool command line utility to show dynamic dependencies for a particular library. Note that this procedure is not recommended for diagnosing Omnis external components directly (DAMs for example). Omnis automatically attempts to load any Omnis external components placed inside the Omnis/xcomp folder.

The following example shows the dynamic dependencies of the SSL-enabled MySQL client library; libmysqlclient.dylib which has been installed to the current user's ~/lib folder.

Because it is a symbolic link, libmysqlclient.dylib actually points to libmyslientclient.21.dylib and this is listed in the output. You can also see that the target file has dependencies on libssl.1.0.0.dylib and libcrypto.1.0.0.dylib.

Items shown with an @rpath entry are specified relative to the parent module's RPATH which is normally burnt into the module at build time. RPATH can include one or more locations that specify where the dynamic loader should look relative to the parent module for its missing dependencies, and normally includes the "current folder" by default.

@loader_path specifies that an item should be placed on the standard library search path. On macOS, this includes the following locations (shown in the order that they are searched): $(HOME)/lib, /usr/local/lib, /lib & /usr/lib. The dynamic loader will also look in the application's Contents/MacOS/Frameworks folder for the parent module, but not for child modules. (For the parent module, the Frameworks folder is searched first).

Items with hard-coded paths must be present in their stated locations. These are normally system libraries.

The compatibility version shows the minimum library version needed for compatibility. The current version shows the version of the library that was located. If the library cannot be located, the current version normally displays as "0.0.0"
All missing and invalid dependencies need to be resolved before Omnis will be able to load the parent module. You can see in the above example that the required libssl and libcrypto files were found on the loader path (either in ~/lib, /usr/local/lib, or in /usr/lib).

 

Linux

On Linux systems, you can use the ldd command line utility to show dynamic dependencies for a particular library. Note that this procedure is not recommended for diagnosing Omnis external components directly (DAMs for example). Omnis automatically attempts to load any Omnis external components placed inside the Omnis/xcomp folder.

The following example shows the dynamic dependencies of the SSL-enabled MySQL client library; libmysqlclient.so.

Dependencies are listed with versioned file names. These are the versions that the parent module was linked against. When the dynamic loader locates each dependency, its location is shown to the right of the => symbol.
The system loader searches for libraries in the following order:

• Folders that are part of the $LD_LIBRARY_PATH environment variable. The omset script normally appends to the value of LD_LIBRARY_PATH before starting Omnis. Multiple folder locations can be separated by colon characters.
• Folders that are listed in the parent module's rpath. rpath is normally burnt into the parent module at build time, but can be edited manually if required.
• Other locations on the standard library search path. In order, these are: /lib & /usr/lib
  Note that the system does not noramlly look in /usr/local/lib> unless it has been configured to do so. See ldconfig for details.

If a library cannot be loaded, it will be shown as "not found". If the item is present, it too may have dependencies on one or more other libraries in which case you can locate the library in question and run ldd on that library.

All missing and invalid dependencies need to be resolved before Omnis will be able to load the parent module. You can see in the above example that the required libssl and libcrypto files were found in the current folder (i.e. in ~/omnisStudio10/.) Other dependencies shown here are standard system libraries, located in the /lib/x86_64 & /usr/lib/x86_64 folders.