What is LD_LIBRARY_PATH and how to use it?

I take part in developing a Java project, which uses some C++ components, thus I need Jacob.dll . (on Windows 7)

I keep getting java.lang.UnsatisfiedLinkError: no JacobDB in java.library.path no matter where I put Jacob.dll.

I looked for possible decisions and the one that I haven’t tried so far is setting the LD_LIBRARY_PATH variable, pointing at the .dll file.

I have little experience and I’m not familiar with what should be the meaning and usage of that variable — can you help me?

6 Answers 6

Typically you must set java.library.path on the JVM’s command line:

LD_LIBRARY_PATH is the predefined environmental variable in Linux/Unix which sets the path which the linker should look in to while linking dynamic libraries/shared libraries.

LD_LIBRARY_PATH contains a colon separated list of paths and the linker gives priority to these paths over the standard library paths /lib and /usr/lib . The standard paths will still be searched, but only after the list of paths in LD_LIBRARY_PATH has been exhausted.

The best way to use LD_LIBRARY_PATH is to set it on the command line or script immediately before executing the program. This way the new LD_LIBRARY_PATH isolated from the rest of your system.

Since you talk about .dll you are on a windows system and a .dll must be placed at a path which the linker searches at link time, in windows this path is set by the environmental variable PATH , So add that .dll to PATH and it should work fine.

Is it possible to add a directory to DLL search path from a batch file or cmd script?

MSDN says that the function SetDllDirectory() can be used to insert a directory into the DLL Search Path. Can this function be accessed from a batch file or cmd script, perhaps using via cscript?

The aim is to have our development version of a dll found before a pre-existing older one in %WINDIR% etc. without having to write a program just for that.

Thanks in advance for your time and thoughts.

3 Answers 3

You can place the DLL in the same path as the executable, which is searched first before %WINDIR%. There’s no way to call SetDllDirectory from a batch file directly.

But, you can insert your DLL directory in the %PATH% variable, and Windows will then find the DLL there.

The aim is to have our development version of a dll found before a pre-existing older one in %WINDIR% etc. without having to write a program just for that.

If the DLL is not in the same folder as the executable Windows will search for the file in the folders specified in the system path. So all you need to do is put your folder at the start of the path.

You can do this using the following batch command:

If your path contains white space you need to use the following batch command:

But remember this path change is only made to the PATH of the current console session. If you close and reopen the console these path changes will be lost.

To clear up dispute on the dll search order (in the comments on @jussij’s answer), here’s the list, drawn from Microsoft’s doc:

If SafeDllSearchMode is enabled, the search order is as follows:

1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

If SafeDllSearchMode is disabled, the search order is as follows:

1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

How do I set the path to a DLL file in Visual Studio?

I developed an application that depends on a DLL file. When I debug my application, the applicationwould complain that:

«This application has failed to start because xxx.dll was not found.»

So I have to copy the DLL file into the same directory as my .vcproj file.

Is there a way to set the project to look for the DLL file in (preferably) some relative path or (not preferred) some absolute path?

Similar concept to how we set include and library path in the project settings.

I mean when I debug my application (hitting F5 ) the above error would pop up.

7 Answers 7

1. Go to project properties (Alt+F7)
2. Under Debugging, look to the right
3. There’s an Environment field.
4. Add your relative path there (relative to vcproj folder) i.e. ..\some-framework\lib by appending PATH=%PATH%;$(ProjectDir)\some-framework\lib or prepending to the path PATH=C:\some-framework\lib;%PATH%
5. Hit F5 (debug) again and it should work.

The search path that the loader uses when you call LoadLibrary() can be altered by using the SetDllDirectory() function. So you could just call this and add the path to your dependency before you load it.

Go through project properties -> Reference Paths

Then add folder with DLL’s

Another possibility would be to set the Working Directory under the debugging options to be the directory that has that DLL.

Edit: I was going to mention using a batch file to start Visual Studio (and set the PATH variable in the batch file). So then did a bit of searching and see that this exact same question was asked not long ago in this post. The answer suggests the batch file option as well as project settings that apparently may do the job (I did not test it).

In your Project properties(Right click on project, click on property button) ▶ Configuration Properties ▶ Build Events ▶ Post Build Events ▶ Command Line.

Edit and add one instruction to command line. for example copy botan.dll from source path to location where is being executed the program.

I had the same problem and my problem had nothing to do with paths. One of my dll-s was written in c++ and it turnes out that if your visual studio doesn’t know how to open a dll file it will say that it did not find it. What i did was locate which dll it did not find, than searched for that dll in my directories and opened it in a separate visual studio window. When trying to navigate through Solution explorer of that project, visual studio said that it cannot show what is inside and that i need some extra extensions, so that it can open those files. Surely enough, after installing the recomended extension (in my case something to do with c++) the

«This application has failed to start because xxx.dll was not found.»

error miraculously dissapeared.

I know this question had been answered years ago, but for those like me who needed to change where the debugger starts the application, change the command property under Project Properties -> Debugging.

What is a DLL

This article describes what a dynamic link library (DLL) is and the various issues that may occur when you use DLLs. It also describes some advanced issues that you should consider when developing your own DLLs.

Original product version: В Windows 10 — all editions
Original KB number: В 815065

Summary

In describing what a DLL is, this article describes dynamic linking methods, DLL dependencies, DLL entry points, exporting DLL functions, and DLL troubleshooting tools.

This article finishes with a high-level comparison of DLLs to the Microsoft .NET Framework assemblies.

For the Windows operating systems, much of the functionality of the operating system is provided by DLL. Additionally, when you run a program on one of these Windows operating systems, much of the functionality of the program may be provided by DLLs. For example, some programs may contain many different modules, and each module of the program is contained and distributed in DLLs.

The use of DLLs helps promote modularization of code, code reuse, efficient memory usage, and reduced disk space. So, the operating system and the programs load faster, run faster, and take less disk space on the computer.

When a program uses a DLL, an issue that is called dependency may cause the program not to run. When a program uses a DLL, a dependency is created. If another program overwrites and breaks this dependency, the original program may not successfully run.

With the introduction of the .NET Framework, most dependency problems have been eliminated by using assemblies.

More information

A DLL is a library that contains code and data that can be used by more than one program at the same time. For example, in Windows operating systems, the Comdlg32 DLL performs common dialog box related functions. Each program can use the functionality that is contained in this DLL to implement an Open dialog box. It helps promote code reuse and efficient memory usage.

By using a DLL, a program can be modularized into separate components. For example, an accounting program may be sold by module. Each module can be loaded into the main program at run time if that module is installed. Because the modules are separate, the load time of the program is faster. And a module is only loaded when that functionality is requested.

Additionally, updates are easier to apply to each module without affecting other parts of the program. For example, you may have a payroll program, and the tax rates change each year. When these changes are isolated to a DLL, you can apply an update without needing to build or install the whole program again.

The following list describes some of the files that are implemented as DLLs in Windows operating systems:

ActiveX Controls (.ocx) files

An example of an ActiveX control is a calendar control that lets you select a date from a calendar.

Control Panel (.cpl) files

An example of a .cpl file is an item that is located in Control Panel. Each item is a specialized DLL.

Device driver (.drv) files

An example of a device driver is a printer driver that controls the printing to a printer.

DLL advantages

The following list describes some of the advantages that are provided when a program uses a DLL:

Uses fewer resources

When multiple programs use the same library of functions, a DLL can reduce the duplication of code that is loaded on the disk and in physical memory. It can greatly influence the performance of not just the program that is running in the foreground, but also other programs that are running on the Windows operating system.

Promotes modular architecture

A DLL helps promote developing modular programs. It helps you develop large programs that require multiple language versions or a program that requires modular architecture. An example of a modular program is an accounting program that has many modules that can be dynamically loaded at run time.

Eases deployment and installation

When a function within a DLL needs an update or a fix, the deployment and installation of the DLL does not require the program to be relinked with the DLL. Additionally, if multiple programs use the same DLL, the multiple programs will all benefit from the update or the fix. This issue may more frequently occur when you use a third-party DLL that is regularly updated or fixed.

DLL dependencies

When a program or a DLL uses a DLL function in another DLL, a dependency is created. The program is no longer self-contained, and the program may experience problems if the dependency is broken. For example, the program may not run if one of the following actions occurs:

• A dependent DLL is upgraded to a new version.
• A dependent DLL is fixed.
• A dependent DLL is overwritten with an earlier version.
• A dependent DLL is removed from the computer.

These actions are known as DLL conflicts. If backward compatibility is not enforced, the program may not successfully run.

The following list describes the changes that have been introduced in Windows 2000 and in later Windows operating systems to help minimize dependency issues:

Windows File Protection

In Windows File Protection, the operating system prevents system DLLs from being updated or deleted by an unauthorized agent. When a program installation tries to remove or update a DLL that is defined as a system DLL, Windows File Protection will look for a valid digital signature.

Private DLLs let you isolate a program from changes that are made to shared DLLs. Private DLLs use version-specific information or an empty .local file to enforce the version of the DLL that is used by the program. To use private DLLs, locate your DLLs in the program root folder. Then, for new programs, add version-specific information to the DLL. For old programs, use an empty .local file. Each method tells the operating system to use the private DLLs that are located in the program root folder.

DLL troubleshooting tools

Several tools are available to help you troubleshoot DLL problems. The following tools are some of these tools.

Dependency Walker

The Dependency Walker tool can recursively scan for all dependent DLLs that are used by a program. When you open a program in Dependency Walker, Dependency Walker does the following checks:

• Dependency Walker checks for missing DLLs.
• Dependency Walker checks for program files or DLLs that are not valid.
• Dependency Walker checks that import functions and export functions match.
• Dependency Walker checks for circular dependency errors.
• Dependency Walker checks for modules that are not valid because the modules are for a different operating system.

By using Dependency Walker, you can document all the DLLs that a program uses. It may help prevent and correct DLL problems that may occur in the future. Dependency Walker is located in the following directory when you install Visual Studio 6.0:

drive\Program Files\Microsoft Visual Studio\Common\Tools

DLL Universal Problem Solver

The DLL Universal Problem Solver (DUPS) tool is used to audit, compare, document, and display DLL information. The following list describes the utilities that make up the DUPS tool:

This utility enumerates all the DLLs on the computer and logs the information to a text file or to a database file.

This utility compares the DLLs that are listed in two text files and produces a third text file that contains the differences.

This utility loads the text files that are created by using the Dlister.exe utility and the Dcomp.exe utility into the dllHell database.

This utility provides a graphical user interface (GUI) version of the Dtxt2DB.exe utility.

DLL Help database

The DLL Help database helps you locate specific versions of DLLs that are installed by Microsoft software products.

DLL development

This section describes the issues and the requirements that you should consider when you develop your own DLLs.

Types of DLLs

When you load a DLL in an application, two methods of linking let you call the exported DLL functions. The two methods of linking are load-time dynamic linking and run-time dynamic linking.

Load-time dynamic linking

In load-time dynamic linking, an application makes explicit calls to exported DLL functions like local functions. To use load-time dynamic linking, provide a header (.h) file and an import library (.lib) file when you compile and link the application. When you do this, the linker will provide the system with the information that is required to load the DLL and resolve the exported DLL function locations at load time.

Run-time dynamic linking

In run-time dynamic linking, an application calls either the LoadLibrary function or the LoadLibraryEx function to load the DLL at run time. After the DLL is successfully loaded, you use the GetProcAddress function to obtain the address of the exported DLL function that you want to call. When you use run-time dynamic linking, you do not need an import library file.

The following list describes the application criteria for when to use load-time dynamic linking and when to use run-time dynamic linking:

If the initial startup performance of the application is important, you should use run-time dynamic linking.

In load-time dynamic linking, the exported DLL functions are like local functions. This makes it easy for you to call these functions.

In run-time dynamic linking, an application can branch to load different modules as required. It is important when you develop multiple-language versions.

The DLL entry point

When you create a DLL, you can optionally specify an entry point function. The entry point function is called when processes or threads attach themselves to the DLL or detached themselves from the DLL. You can use the entry point function to initialize data structures or to destroy data structures as required by the DLL. Additionally, if the application is multithreaded, you can use thread local storage (TLS) to allocate memory that is private to each thread in the entry point function. The following code is an example of the DLL entry point function.

When the entry point function returns a FALSE value, the application will not start if you are using load-time dynamic linking. If you are using run-time dynamic linking, only the individual DLL will not load.

The entry point function should only perform simple initialization tasks and should not call any other DLL loading or termination functions. For example, in the entry point function, you should not directly or indirectly call the LoadLibrary function or the LoadLibraryEx function. Additionally, you should not call the FreeLibrary function when the process is terminating.

In multithreaded applications, make sure that access to the DLL global data is synchronized (thread safe) to avoid possible data corruption. To do this, use TLS to provide unique data for each thread.

Export DLL functions

To export DLL functions, you can either add a function keyword to the exported DLL functions or create a module definition (.def) file that lists the exported DLL functions.

To use a function keyword, you must declare each function that you want to export with the following keyword:
__declspec(dllexport)

To use exported DLL functions in the application, you must declare each function that you want to import with the following keyword: __declspec(dllimport)

Typically, you would use one header file that has a define statement and an ifdef statement to separate the export statement and the import statement.

You can also use a module definition file to declare exported DLL functions. When you use a module definition file, you do not have to add the function keyword to the exported DLL functions. In the module definition file, you declare the LIBRARY statement and the EXPORTS statement for the DLL. The following code is an example of a definition file.

Sample DLL and application

In Visual C++ 6.0, you can create a DLL by selecting either the Win32 Dynamic-Link Library project type or the MFC AppWizard (dll) project type.

The following code is an example of a DLL that was created in Visual C++ by using the Win32 Dynamic-Link Library project type.

The following code is an example of a Win32 Application project that calls the exported DLL function in the SampleDLL DLL.

In load-time dynamic linking, you must link the SampleDLL.lib import library that is created when you build the SampleDLL project.

In run-time dynamic linking, you use code that is similar to the following code to call the SampleDLL.dll exported DLL function.

When you compile and link the SampleDLL application, the Windows operating system searches for the SampleDLL DLL in the following locations in this order:

The application folder

The current folder

The Windows system folder

The GetSystemDirectory function returns the path of the Windows system folder.

The Windows folder

The GetWindowsDirectory function returns the path of the Windows folder.

The .NET Framework assembly

With the introduction of .NET and the .NET Framework, most of the problems that are associated with DLLs have been eliminated by using assemblies. An assembly is a logical unit of functionality that runs under the control of the .NET common language runtime (CLR). An assembly physically exists as a .dll file or as an .exe file. However, internally an assembly is different from a Microsoft Win32 DLL.

An assembly file contains an assembly manifest, type metadata, Microsoft intermediate language (MSIL) code, and other resources. The assembly manifest contains the assembly metadata that provides all the information that is required for an assembly to be self-describing. The following information is included in the assembly manifest:

• Assembly name
• Version information
• Culture information
• Strong name information
• The assembly list of files
• Type reference information
• Referenced and dependent assembly information

The MSIL code that is contained in the assembly cannot be directly executed. Instead, MSIL code execution is managed through the CLR. By default, when you create an assembly, the assembly is private to the application. To create a shared assembly requires that you assign a strong name to the assembly and then publish the assembly in the global assembly cache.

The following list describes some of the features of assemblies compared to the features of Win32 DLLs:

When you create an assembly, all the information that is required for the CLR to run the assembly is contained in the assembly manifest. The assembly manifest contains a list of the dependent assemblies. Therefore, the CLR can maintain a consistent set of assemblies that are used in the application. In Win32 DLLs, you cannot maintain consistency between a set of DLLs that are used in an application when you use shared DLLs.

In an assembly manifest, version information is recorded and enforced by the CLR. Additionally, version policies let you enforce version-specific usage. In Win32 DLLs, versioning can’t be enforced by the operating system. You must make sure that DLLs are backward compatible.

Assemblies support side-by-side deployment. One application can use one version of an assembly, and another application can use a different version of an assembly. Starting in Windows 2000, side-by-side deployment is supported by locating DLLs in the application folder. Additionally, Windows File Protection prevents system DLLs from being overwritten or replaced by an unauthorized agent.

Self-containment and isolation

An application that is developed by using an assembly can be self-contained and isolated from other applications that are running on the computer. This feature helps you create zero-impact installations.

An assembly is run under the security permissions that are supplied in the assembly manifest and that are controlled by the CLR.

An assembly can be developed by using any one of the supported .NET languages. For example, you can develop an assembly in Microsoft Visual C#, and then use the assembly in a Visual Basic .NET project.