Solution
When a Call Library Function Node attempts to load a shared library specified by name (as opposed to by path), LabVIEW relies on a modified version of the system search algorithm defined by your platform. Therefore, you must save the shared library in one of the directories that the system search algorithm for your platform searches.
NOTE: This document addresses only how LabVIEW locates shared libraries specified by name in the Call Library Function dialog box. If you specify a shared library by path, LabVIEW uses its own algorithm to locate the shared library. Specifying a shared library by path produces different consequences when you distribute or relocate your VIs and applications. Refer to the Specifying the Locations of Shared Libraries on Disk topic in the LabVIEW Help (linked below) for more information about these consequences as well as how LabVIEW loads a shared library by path.
Windows
When you specify a shared library by name on Windows, LabVIEW locates the shared library by calling the Win32 function LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH. The Dynamic-Link Library Search Order topic in MSDN (linked below) describes the specific directories that the function searches. However, LabVIEW makes the following two modifications to this search algorithm:
- LabVIEW searches the LabVIEW resource directory (
<labview>\resource) before any other location. - LabVIEW sets the current directory to the LabVIEW resource directory (
<labview>\resource) before calling LoadLibraryEx. After LoadLibraryEx finishes executing, LabVIEW restores the current directory to its previous value.
Linux
When you specify a shared library by name on Linux, LabVIEW locates the shared library by calling the dlopen function using RTLD_NOW for the mode parameter. Refer to the main page for dlopen for more details about its behavior.This function searches in the following locations:
RPATHLD_LIBRARY_PATH_CS_LIBPATH
LabVIEW does not define the values of LD_LIBRARY_PATH or _CS_LIBPATH, but LabVIEW does specify the following locations for RPATH.
For VIs running in the LabVIEW development environment, RPATH includes the following directories, in order:
| General Location | Most Common Path |
<labview>/patchlib | /usr/local/natinst/LabVIEW <year> |
/usr/X11R6/lib | /usr/X11R6/lib |
/usr/lib | /usr/lib |
<labview> | /usr/local/natinst/LabVIEW <year> |
<labview>/linux | /usr/local/natinst/LabVIEW <year>/linux |
<labview>/resource | /usr/local/natinst/LabVIEW <year>/resource |
For LabVIEW-built applications that run in the LabVIEW Run-Time Engine, RPATH includes the following directories, in order:
| General Location | Most Common Path |
<labview RTE>/patchlib | /usr/local/lib/LabVIEW <year>/patchlib |
<labview RTE> | /usr/local/lib/LabVIEW <year> |
patchlib directory in the parent directory of <labview RTE> | /usr/local/lib/patchlib |
/usr/X11R6/lib | /usr/X11R6/lib |
/usr/lib | /usr/lib |
parent directory of <labview RTE> | /usr/local/lib |
<labview RTE>/linux | /usr/local/lib/LabVIEW <year>/linux |
linux directory in the parent directory of <labview RTE> | /usr/local/lib/linux |
resource directory in the parent directory of <labview RTE> | /usr/local/lib/resource |
Mac OS X
When you specify a shared library by name on Mac OS X, LabVIEW can load both frameworks and dylibs. LabVIEW initially attempts to load both kinds of shared libraries as a framework by searching in the following directories, in order:
| General Location | Most Common Path |
| Application's private framework directory | LabVIEW.app/Contents/Frameworks or <Application>.app/Contents/Frameworks |
<labview>/resource | /Applications/National Instruments/LabVIEW <year>/resource |
| User Frameworks directory | ~/Library/Frameworks |
<User Application Support>/National Instruments and all subdirectories | ~/Library/Application Support/National Instruments and all subdirectories |
| Local Frameworks directory | /Library/Frameworks |
<Local Application Support>/National Instruments and all subdirectories | /Library/Application Support/National Instruments and all subdirectories |
| System Frameworks directory | /System/Library/Frameworks |
| System Private Frameworks directory | /System/Library/PrivateFrameworks |
If LabVIEW fails to load the shared library as a framework, LabVIEW then tries to load the shared library as a dylib by using the dlopen function. Refer to the Mac OS X Developer Library: dlopen(3) Mac OS X Manual Page (linked below) for the search order performed by that function.
NOTE: If you specify a shared library name as library.*, LabVIEW replaces .* with .framework.