Calling the lpsolve API from your application

There are two ways to call the lpsolve API from an application:

• Statically
• Dynamically

Statically means that the lpsolve code is statically linked to the code. This means that the program does not need extra files to be able to call lpsolve since the code is already contained in the executable. The executable will thus be larger. This can only be done if you have the source code of your program and you can recompile it and link it with the lpsolve code. Not all programming languages have the possibility to statically link code. For example VB6 does not have a way to do that. The advantage of this way of calling the lpsolve library is that you don't have to provide extra files with your executable since the library is already in the exe. The disadvantage is that you must recompile (or at least link) the program with the lpsolve code when an update of lpsolve is needed. There are two ways to link your application with the lpsolve code. The first way is add the needed lpsolve source code to the project and compile it together as one unit. This is most probably only possible when the code is also written in C/C++ (however not always since for example .NET allows to link for example C# code with C code). The disadvantage of this way of working is that you have to revise your project when you use a new version of lpsolve since there could be files added or removed in the lpsolve package. Also you may have to define some defines. A better way of working is making use of the lpsolve library. Under DOS/Windows this is called lpsolve5.lib, under Unix/Linux liblpkit5.a. The advantages are that other languages (like Pascal) can also link with such a library, your project is not overloaded with the lpsolve source files and also not unimportant, the linker only takes the code from the library that you really use resulting in a smaller executable. One disadvantage is that you cannot debug and step trough the lpsolve code then, if you would want to do that.

Dynamically means that the lpsolve code is dynamically linked to your code. This means that it is linked to your program when the executable is started or even only when you make calls to the lpsolve library. The lpsolve library is then not linked with the executable and is provided in a separate file. Under Windows this is a dll (lpsolve5.dll), under Unix/Linux this is a shared library (liblpkit5.so). You must distribute this separate library with your program to make it work. The library must be located on a place that can be found by the program. There are several advantages of this way of working. Almost all programming languages have a way to call dynamic libraries or even can only call libraries that way. One example is VB6. Another advantage is that it is easier to update the package. The program doesn't have to be recompiled/relinked. You only have to provide a new lpsolve library.

Needed sources files

The following source files must at least be added to your project:

colamd/colamd.c
commonlib.c
lp_MDO.c
lp_crash.c
lp_etaPFI.c
lp_Hash.c
lp_lib.c
lp_matrix.c
lp_mipbb.c
lp_MPS.c
lp_presolve.c
lp_pricePSE.c
lp_report.c
lp_scale.c
lp_simplex.c
lp_SOS.c
lp_utils.c
lp_wlp.c

All header (.h) files from lpsolve must be accessible. Most compilers use the directive -Ipath with path the location to the header files. Note that the colamd directory also contains a header file that must be included.

If you also need the lp parser to read an lp model (read_lp, read_LP) then you must also include the files lp_rlp.c and yacc_read.c and define the symbol PARSER_LP. Most compilers use the directive -DPARSER_LP to do that. If you forget to define this symbol then the linker will give a link error saying that the symbols read_lp, read_LP are already defined. Also define the symbol YY_NEVER_INTERACTIVE (-DYY_NEVER_INTERACTIVE). This to disable the interactive mode of the lex parser and remove the dependency on isatty() routine which not available in all environments.

If you also need the CPLEX lp parser to read an lp model (read_lpt, read_LPT) and/or to write a CPLEX lp model, then you must also include the files lp_rlpt.c, lp_wlpt.c and yacc_read.c and define the symbol PARSER_CPLEX. Most compilers use the directive -DPARSER_CPLEX to do that. If you forget to define this symbol then the linker will give a link error saying that the symbols read_lpt, read_LPT, write_lpt, write_LPT are already defined. Also define the symbol YY_NEVER_INTERACTIVE (-DYY_NEVER_INTERACTIVE). This to disable the interactive mode of the lex parser and remove the dependency on isatty() routine which not available in all environments.

Note that lp_rlp.c, lp_rlp.h, lp_rlpt.c, lp_rlpt.h may give you some warnings when they are compiled. This is 'normal'. These files are not human-written, but generated from yacc/bison/lex tools from the corresponding .y and .l files. These tools don't seem to care much in generating code that is fully Ansi compliant and without warnings. Normally they can be ignored.

Note that there are more .c files in the lpsolve directory. You don't have to (even may not) include these in your project also. This because there files are either automatically included by the other source files or are needed for other functionality.

Statically link your application with the lpsolve code

Statically link your application with the lpsolve library

Dynamically link your application with the lpsolve library

There are two ways of linking a dynamic library to the application: Implicit and Explicit linking. It depends on the programming language which way of linking is supported. Some support only one of the two, some can do both ways.

With Implicit Linking, the shared library file gets loaded into memory as soon as we execute the client program. If implicitly linked, the library is not removed from memory unless the application is terminated. However, if there are other applications in memory that are using the library, it is not removed from memory till the last of these applications is terminated.
If we want, we can defer the loading of the library till the time a call to the exported function in the library is not made. This is known as Explicit Linking. Explicit linking is more appropriate for interpreted languages such as Visual Basic, but it can also be used from C/C++ if we need to.

If Implicit Linking is used, a link (or import) library must be provided to the linker to resolve the symbols. In the code, the function calls are made as if all symbols are available.
If Explicit Linking is used, the library is explicitly loaded in memory via a special API call and the routines are also explicitly called via API calls. It should be clear that Explicit linking requires more coding than Implicit linking, but it allows you do load the library only when you need it and even decide at runtime from which library to call the routines.

Some may see Implicit linking as 'early binding' and Explicit linking as 'late binding'. Although it is not exactly the same, the analogy is true. Just like 'early binding', with Implicit linking, the symbols are resolved and checked at compile (actually link) time. There is strong type checking and less chance to pass wrong arguments. Just like 'late binding', with Explicit linking, the symbols are resolved and checked at runtime. The type checking is loose and there is chance that wrong parameters are passed to the function with possible disastrous results. But with the flexibility to dynamically load and call functions.
For Windows, there is a good article explaining all this: DLLs for Beginners

WINDOWS: Call the lpsolve dll from C/C++

Implicit linking

Explicit linking

#include <stdio.h>

#include "lp_lib.h"

main()
{
  lprec *lp;
  HINSTANCE lpsolve;
  make_lp_func *_make_lp;
  delete_lp_func *_delete_lp;

  lpsolve = LoadLibrary("lpsolve5.dll");

  if (lpsolve == NULL) {
    printf("Unable to load lpsolve shared library\n");
    return(FALSE);
  }
  _make_lp = (make_lp_func *) GetProcAddress(lpsolve, "make_lp");
  _delete_lp = (delete_lp_func *) GetProcAddress(lpsolve, "delete_lp");

  lp = _make_lp(0,4);

  /* ... */

  _delete_lp(lp);

  FreeLibrary(lpsolve);
}

WINDOWS: Call the lpsolve dll from VB (also VBS Excel, Word, Access)

These environments support only Explicit linking. However it is easier than in C. Via a DECLARE statement, the API routines are declared and can immediately be called. The LoadLobrary/GetProcAddress API calls are not needed. To make things even easier, a class file is made to access the lpsolve library. It is called lpsolve5.cls. See the VB/Excel demos to see how it works.

WINDOWS: Call the lpsolve dll from VB.NET, C#

This is analog as for VB. These environments probably also allow to use implicit linking, but this is not investigated. There is also a class library made to call the lpsolve library. It is called lpsolve5.vb and lpsolve5.cs
See the demos for how it works.

Building the lpsolve shared library