LabVIEW Shared Library Directories Used by Call Library Function Node

Updated Mar 25, 2021

Reported In


  • LabVIEW

Operating System

  • Windows
  • Linux
  • Mac OS X

Issue Details

One of my Call Library Function Nodes in LabVIEW cannot find a shared library whose name I specified in the Call Library Function dialog box. Where can I save the shared library so that LabVIEW can find it?


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.


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.



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:


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 LocationMost Common Path
<labview>/patchlib/usr/local/natinst/LabVIEW <year>
<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 LocationMost 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
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 LocationMost Common Path
Application's private framework 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.