Most issues are linked with either the calling program (such as AMPL or MATLAB) not finding the Knitro binaries, or with Knitro not finding the license file. These are discussed first.

License and PATH issues

Below is a list of steps to take if you have difficulties installing Knitro.

  • Create an environment variable ARTELYS_LICENSE_DEBUG and set it to 1. This will enable some debug output printing that will indicate where the license manager is looking for a license file. See Section 4.1 of the Artelys License Manager User’s Manual for more details on how to set the ARTELYS_LICENSE_DEBUG environment variable and generate debugging information.
  • Ensure that the user has the correct permissions for read access to all libraries and to the license file.
  • Ensure that the program calling Knitro is 32-bit (or 64-bit) when Knitro is 32-bit (or 64-bit). As an example, you cannot use Knitro 32-bit with MATLAB 64-bit or vice versa. This applies to the Java Virtual Machine and Python as well.
  • On Windows, make sure that you are setting system environment variables rather than user environment variables, when setting environment variables for Knitro (or, if using user environment variables, that the correct user is logged in).
  • Knitro has multiple options for installing license files. If the procedure you are trying is not working, please try an alternative procedure.
  • If you have multiple Knitro executable files or libraries of the same name on your computer, make sure that the one being used is really the one you intend to use (by making sure it appears first in the definition of the appropriate environment variable).

Please also refer to the Artelys License Manager User’s Manual provided with your distribution for additional installation and troubleshooting information.

MATLAB issues

Below are some troubleshooting tips specific to the Knitro/MATLAB interface.

  • Make sure the Knitro/MATLAB interface files knitromatlab_mex.mex*, knitromatlab.m, knitromatlab_mip.p, etc., are located in a folder/directory where they can be found by your MATLAB session. See Installation for more information on adding the Knitro/MATLAB interface files to your MATLAB path.

  • On Mac OS X, if Knitro/MATLAB is not finding the license file (or a library), try starting MATLAB from the Terminal by typing “matlab” from a Terminal window. Sometimes environment variables are not inherited properly by a MATLAB session on Mac OS X when the session is started by double-clicking on the MATLAB icon.

  • Ensure that the MATLAB installation calling Knitro is 32-bit (or 64-bit) when Knitro is 32-bit (or 64-bit). You cannot use Knitro 32-bit with MATLAB 64-bit or vice versa.

  • If you encounter the error message cannot load any more object with static TLS this is a MATLAB bug (bug# 961964) on Linux. You may try one of the following workaround, if the issue remains, you may contact Mathworks directly.

    1. Insert ones(10)*ones(10); in the file startup.m.
    2. Preload any library before starting MATLAB using the environment variable LD_PRELOAD (ex: export LD_PRELOAD=/usr/lib64/
    3. Run MATLAB without the GUI by running the following command from a terminal matlab -nojvm.

Symbolic links, on systems that support them, are an alternative to copying / renaming the file.

Python interface issues

If you are using the Python interface on a Linux or Unix platform, you may need to use a Python distribution that has been compiled with the -fopenmp flag of the gcc/g++ compiler in order to use the standard Knitro libraries. Otherwise, you should use the sequential Knitro libraries. See Linux and Mac OS X compatibility issues for more information.

Issues with LD_LIBRARY_PATH on Ubuntu

In Ubuntu, setting LD_LIBRARY_PATH directly was reported to fail; using ldconfig solved the problem as follows:

  • Go to /etc/ directory;
  • Create a new configuration file in this directory;
  • Set all your environment variables in this file and save it;
  • Execute sudo ldconfig -v at the prompt.

Loading external third party dynamic libraries

Some user options instruct Knitro to load dynamic libraries at runtime. This will not work unless the executable can find the desired library using the operating system’s load path. Usually this is done by appending the path to the directory that contains the library to an environment variable. For example, suppose the library to be loaded is in the Knitro lib directory. The instructions below will correctly modify the load path.

  • On Windows, type (assuming Knitro 10.2.0 is installed at its default location):

    set PATH=%PATH%;C:\Program Files\Artelys\knitro-|release|-z\lib
  • On Mac OS X, type (assuming Knitro 10.2.0 is installed at /tmp):

    export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/tmp/knitro-|release|-z/lib
  • If you run a Unix bash shell, then type (assuming Knitro 10.2.0 is installed at /tmp):

    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/tmp/knitro-|release|-z/lib
  • If you run a Unix csh or tcsh shell, then type (assuming Knitro 10.2.0 is installed at /tmp):

    setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH:/tmp/knitro-|release|-z/lib

Linux and Mac OS X compatibility issues

Linux platforms sometimes generate link errors when building the programs in examples/C. Simply type “gmake” and see if the build is successful. You may see a long list of link errors similar to the following:

../lib/libknitro.a(.text+0x28808): In function `ktr_xeb4':
: undefined reference to `std::__default_alloc_template<true, 0>::deallo
cate(void*, unsigned int)'
../lib/libknitro.a(.text+0x28837): In function `ktr_xeb4':
: undefined reference to `std::__default_alloc_template<true, 0>::deallo
cate(void*, unsigned int)'
../lib/libknitro.a(.text+0x290b0): more undefined references to `std::__
default_alloc_template<true, 0>::deallocate(void*, unsigned int)' follow
../lib/libknitro.a(.text+0x2a0ff): In function `ktr_x1150':
: undefined reference to `std::basic_string<char, std::char_traits<char>
, std::allocator<char> >::_S_empty_rep_storage'
../lib/libknitro.a(.text+0x2a283): In function `ktr_x1150':
: undefined reference to `std::__default_alloc_template<true, 0>::deallo
cate(void*, unsigned int)'

This indicates an incompatibility between the libstdc++ library on your Linux distribution and the library that Knitro was built with. The incompatibilities may be caused by name-mangling differences between versions of the gcc/g++ compiler, and by differences in the Application Binary Interface of the two Linux distributions. The best fix is for Artelys to rebuild the Knitro binaries on the same Linux distribution of your target machine (matching the Linux brand and release, and the gcc/g++ compiler versions).

Other link errors may be seen on 64-bit Linux and Mac OS X platforms related to undefined references to “omp” or “pthread” symbols. For example, the link errors may look something like

undefined reference to `pthread_setaffinity_np@GLIBC_2.3.4'

on Linux, or

Undefined symbols:
      "_GOMP_parallel_start", referenced from:

on Mac OS X. This implies either that the dynamic libraries needed for OpenMP (usually provided in system directories, or in the Knitro lib directory for the Mac OS X distribution) are not being found, or that the version of gcc/g++ used for linking is not compatible with the OpenMP features used in the standard Knitro 10.2 libraries. To solve this issue, be sure that the LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on Mac OS X) environment variable includes the Knitro lib directory, or try linking against the sequential versions of the Knitro libraries provided with your platform distribution on Linux. See the README file provided in the Knitro lib directory for more information

Windows compatibility issues

Using the “dll” version of the Knitro library on Windows (i.e. linking against knitro1020.lib) is recommended and should be compatible across multiple versions of the Microsoft Visual C++ (MSVC) compiler.