Draft Writeup of June 11, 2000


       When AMPL starts to run, it looks for two shared or dynamic link libraries, ampltabl.dll and amplfunc.dll, from which it tries to import functions and table handlers. We describe here the rules that AMPL follows in looking for each of these libraries. We then introduce new load, unload, and reload commands that can be used to explicitly change the available imported functions and table handlers during an AMPL session.

       The ampl/solvers/funclink directory in netlib provides examples and makefiles for creating suitable shared libraries and linking them to solvers under various systems. For a further introduction, see the README file in the funclink directory.

Loading rules for ampltabl.dll

       The ampltabl.dll library is intended for installation-standard or vendor-provided table handlers and (less commonly) imported functions. Thus AMPL uses your system's standard search rules to look for ampltabl.dll.

       On most systems, the default search rules can be modified by the installation and can be affected by how AMPL was linked. On many systems, the search rules for ampltabl.dll can also be affected by the setting of an environment variable that specifies a list of directories, separated by semicolons on Microsoft systems and by colons on most other systems. Except where noted otherwise, the current directory is generally excluded unless it appears in the directory list in relevant environment variable.

       Below is a summary of the library search rules for ampltabl.dll on some popular systems.

Operating system AMPL typically seeks ampltabl.dll in: Special notes
(versions 4.2 and later)
1. directories in the LIBPATH environment variable
2. /usr/lib
3. /lib
FreeBSD 1. directories in the LD_LIBRARY_PATH environment variable
2. /usr/lib
HPUX 1. the current directory
2. /usr/lib
3. /usr/ccs/lib
Linux 1. directories in the LD_LIBRARY_PATH environment variable
2. /usr/lib
3. /lib
Details may depend in part on the particular version of Linux.
Microsoft Windows
(95, 98 or NT)
1. the folder from which ampl.exe loaded
2. the current folder
5. folders in the PATH environment variable
If your Windows folder is other than C:\WINDOWS, (3) and (4) are adjusted accordingly.
(DEC Unix)
1. the current directory
2. directories in the LD_LIBRARY_PATH environment variable
3. /usr/shlib
4. /usr/ccs/lib
5. /usr/lib/cmplrs/cc
6. /usr/lib
7. /usr/local/lib
Solaris 1. directories in the LD_LIBRARY_PATH environment variable (32-bit "ampl")
2. directories in the LD_LIBRARY_PATH_64 environment variable (64-bit "ampl")
3. /usr/ccs/lib
4. /usr/lib

Loading rules for amplfunc.dll

       The amplfunc.dll library is intended for functions and (less commonly) special table handers that you yourself provide. Thus AMPL looks for amplfunc.dll only in the invocation directory -- the directory (or folder) in which AMPL starts to run.

       AMPL's -i command-line option and AMPLFUNC environment variable provide ways to change the name "amplfunc.dll" to something else and to determine the directory in which it is sought. Invoking AMPL from the command line with

ampl -i-
tells AMPL not to look for amplfunc.dll at all;
ampl -i dirname
tells AMPL to look in directory dirname for amplfunc.dll;
ampl -i filename
tells AMPL initially to import functions and table handlers from file filename rather than amplfunc.dll; and
ampl -i?
tells AMPL to summarize the current -i command-line options. If no -i command-line option appears but environment variable AMPLFUNC is set to a nonempty value, AMPL behaves as though it had been invoked by
ampl -i "$AMPLFUNC"
AMPL also accepts other command-line options and reads files specified on its command line. File names must appear after command-line options; where -i appears among them does not matter. (For a summary of other currently available command-line options, invoke ampl -?.)

Explicit library loading and unloading

       The load, unload, and reload commands permit changing the available imported functions and table handlers during an AMPL session. These commands have the forms

load    [ libname [, libname . . . ] ];
[ libname [, libname . . . ] ];
[ libname [, libname . . . ] ];
in which libname is the name of a library file (in one of the usual forms for filenames, possibly a full pathname). Naturally, load causes the contents of any specified libraries to be loaded and made available to AMPL, while unload causes the contents of specified libraries to be unloaded and hence to become unavailable to AMPL thereafter. The reload command first unloads its arguments, then loads them. This can change the order of loaded libraries and affect the visibility of imported functions: if a function appears in more than one library, the one in the first library loaded is used.

       With no libname arguments, "load;" loads all the libraries currently in $AMPLFUNC; "unload;" unloads all currently loaded libraries, and "reload;" reloads them, which might be useful if some have been recompiled. On the other hand, the "reset;" command does not cause libraries to be unloaded or reloaded.

       When libnames are mentioned in the load and unload commands, option AMPLFUNC is modified to reflect the full pathnames of the currently loaded libraries. Several automatically updated system sets provide further information about the currently loaded libraries:

_LIBS         currently loaded libraries
_AVAILFUNCS   currently available imported functions
_AVAILFUNC2   (available function, library) pairs
_SFUNCS       imported functions that "solve;" currently uses
Names that appear in _AVAILFUNCS must be declared before they can appear in declarations or commands. With the help of _AVAILFUNC2 you can see which library is currently supplying an available imported function.

Comments or questions?
Write to info@ampl.com or use our comment form.

Return to the relational database writeup.

Return to the AMPL update page.

Return to the AMPL home page.