|
libSBML C# API
5.18.0
|
|
libSBML C# API
5.18.0
|
This section explains how to build libSBML from the source distribution.
LibSBML supports two build systems: CMake, and GNU autoconf plus GNU make. CMake is preferred and is the only one supported for building SBML Level 3 package extensions; the use of GNU autoconf and GNU make is deprecated but is currently still used to build the documentation. In all cases below, you will need to download the libSBML source code archive from the download area on SourceForge.net then unpack the archive somewhere on your computer.
CMake is a cross-platform build configuration system that can be used to generate makefiles as well as project files for common development environments such as Visual Studio, Eclipse, Xcode and CodeBlocks. If you do not already have CMake installed on your system, please make sure to download and install a copy of CMake 3.10 or later from cmake.org on your computer system.
Next, start up the CMake graphical user interface (GUI). This is a configuration tool that allows you to select options for configuring your libSBML build and then generate makefiles for running the actual build. The GUI will look something similar to the following screenshot:
Screenshot of CMake when it first starts up. Shown here is the Mac OS X version of CMake; it will look similar but not identical on other operating systems.
In the CMake GUI interface, first click on the Browse Source... button and navigate to the directory where you unpacked the libSBML source code archive on your file system. Next, check the value of the field Where to build the binaries. We use so-called “out-of-source builds” for libSBML, meaning that CMake will place compiled binary files in a separate build directory, not intermixed with the source files. If the field for the build directory in the CMake GUI is blank, or CMake filled it with a different value than what you prefer, click on the Browse Build... button to change the directory.
After filling in the fields at the top of the interface, click on the Configure button. If this is the first time you have executed CMake's Configure command in the libSBML source directory, you may see a dialog such as the following, asking you whether it can create a subdirectory where it will compile libSBML. Click on the "Yes" button if the directory location is acceptable.
Dialog presented by CMake before it creates the subdirectory that it will use to compile libSBML.
Screenshot of the Configure screen under Mac OS X.
Unless you have special requirements, select the default choices of "Unix Makefiles" and "Use default native compilers", then click the Done button. This will close the selection dialog, whereupon CMake will read the libSBML configuration files and populate the options area in the CMake GUI with various options for controlling how libSBML is built. These new options are displayed in red, as illustrated in the following screenshot.
Screenshot of the CMake interface after the configuration step.
In this panel, you can set values for various libSBML configuration/build options. To find out the meaning of a particular option, hover your mouse/pointer over the item for a few seconds until a tooltip appears—it will provide a short description of the option under the cursor. There are numerous options available; below, we point out just a few that are especially popular for customization:
CMAKE_INSTALL_PREFIX: the location into which the compiled
libSBML libraries. After clicking on this field, you can type a directory path
directly into the field or click on the square
... icon to
invoke a file/open dialog.
WITH_JAVA, WITH_PYTHON, etc.: toggle whether to
build the language bindings for programming languages supported by libSBML,
such as C#, Java, JavaScript, MATLAB, Octave, Perl, Python, R, Ruby, and possibly others.
If you need to indicate an explicit path to the interpreter (e.g., for
Python), click the "Advanced" checkbox in the upper part of the
CMake GUI to gain access to additional configuration options.
(For Python, they are PYTHON_EXECUTABLE,
PYTHON_INCLUDE_DIR and PYTHON_LIBRARY.)
ENABLE_COMP, ENABLE_QUAL, etc.: toggle whether
support for various SBML Level 3 packages is included. The names
following the ENABLE_ part are the package nicknames:
“comp” for the Hierarchical Model Composition package,
“qual” for the Qualitative Models package, and so on.
WITH_EXPAT, WITH_XERCES: by default, libSBML will
use the libxml2 XML library. If you
prefer to use Expat (version 1.95.8 or greater) or Xerces (version 2.7.0 or greater), select one of these options instead, and set WITH_LIBXML to false.Note that selecting options and configuring libSBML using the GUI actually involves a two-step process:
Once you are satisfied with the options selected and there are no more red items the dialog box, click on the Generate button. This will cause CMake to create configuration files for the compilation environment you selected in the beginning (e.g., Visual Studio under Windows, or regular Unix makefiles under Mac OS or Linux, and so on). The files will be placed in the "build" directory you indicated in the second line of the CMake GUI.
Now please proceed to Section 1.3, Compiling and installing LibSBML.
Warning: the use of GNU autoconf and GNU make is deprecated. It cannot be used to properly build the libSBML packages, and it has only been retained to build the libSBML documentation. Please use the CMake-based build system unless you are attempting to build the documentation.
First, in a shell (terminal), cd
into the directory where you unpacked the libSBML source code
archive. (It will have a name such as
libSBML-5.18.0-Source.)
If you only want to build the C and C++ interfaces and install
libSBML into /usr/local (the default), then configuring
libSBML is simply a matter of executing the following command:
./configure
LibSBML requires a separate XML library for low-level XML tokenizing
and Unicode support. It will by default attempt to use the libxml2 XML library; if you
do not have libxml2 version 2.6.16 or later on your system, the
configure program will terminate with an error explaining it
cannot find libxml2. (Important: libSBML needs the development
libraries for libxml2, not only the runtime library, which on systems such
as Linux means that you need to have installed both the basic
libxml2 distribution and the -dev distribution. These
distributions typically have the root names libxml2
and libxml2-dev, often followed by a version number.)
Instead of using libxml2, you can inform the configure
program to use the Expat or Xerces libraries.
Many Linux and other UNIX-like systems provide one or more of these
libraries either as part of their standard distribution or as an optional
RPM, Debian, Mandrake or other package distributions. To use Expat, run
the libSBML configuration program as follows:
./configure --with-expat
And for Xerces, use
./configure --with-xerces
Compatibility warning: The default XML parser library used by libSBML is libxml2. If you chose to use another XML parser library instead, beware there is a known bug in Xerces 2.6.0 that cannot be worked around at this time and causes errors in software using it. Xerces versions 2.2 – 2.5, and 2.7.0 and above, are known to work properly, and all Expat versions above 1.95.8 are also known to work.
If your copy of libxml2, Expat, or Xerces is installed in a
non-standard location on your computer system (e.g., a private home
directory), configure may not be able to find it by itself.
In this case, configure needs to be told explicitly where to
find the libraries. Use the following forms:
./configure --with-libxml="DIR"
or
./configure --with-xerces="DIR"
or
./configure --with-expat="DIR"
where DIR is the
parent directory of where the include and lib
directories of Xerces, Expat or libxml2 (whichever one you are trying to
use) is located. For example, on Mac OS X, if you used Fink to install Expat in
Fink's default software tree, you would configure libSBML using the
following command:
./configure --with-expat="/sw"
By default, during the installation phase (i.e., when running
make install, discussed below), the libSBML installation
commands will copy header files to /usr/local/include/sbml,
the shared and static library files to /usr/local/lib, and
documentation files to
/usr/local/share/doc/libsbml-VERSION--prefixconfigure program. For example,
./configure --prefix="/my/favorite/path"
Of course, you can combine the flags to configure, giving both
--prefix--with-expat--with-xerces--with-libxml
LibSBML's core is written in C and C++, but libSBML comes with APIs for
other languages as well. To enable the library extensions for C#, Java,
JavaScript, MATLAB, Octave, Perl, Python, R and/or Ruby, you need to supply additional
options to configure. These options are
--with-csharp--with-java--with-javascript--with-matlab--with-octave--with-perl--with-python--with-r--with-ruby/Applications/MATLAB_R2010a.app, the proper argument would be
./configure --with-matlab=/Applications/MATLAB_R2010a.app
If you want to build multiple language bindings for libSBML, combine multiple flags together as in the following example:
./configure --with-java --with-python
Some of the language interfaces provide additional configuration options
besides the basic --with-language option. In particular,
for Python and C#, there are options allowing you to specify the language
interpreter that should be used, which is important for systems that have
multiple versions installed. For example, to indicate that you want to use
the Apple-supplied version of Python 2.6 on a Mac OS X 10.7 system
(which has versions 2.5, 2.6 and 2.7 located in /usr/bin), you
could use the following options:
./configure --with-python --with-python-interpreter=/usr/bin/python2.6
Please run configure --helpconfigure.
The libSBML distribution ships with certain interface files provided, so that you do not need to have the software necessary to recreate them. However, if you obtained the libSBML distribution from the project SVN repository on SourceForge, or you want to recreate the files deliberately, you may need to configure libSBML to use SWIG to regenerate the libSBML language interfaces. Please see the section below on using SWIG.
Finally, note that these additional language bindings are implemented
via foreign function interfaces in the respective languages; in all cases,
the core C/C++ libSBML library still must be compiled and installed. The
language binding files are not standalone implementations. For
instance, the Java language API files consist of a file named
libsbmlj.jar and a native object library file named (depending
on the operating system) libsbmlj.jnilib (Mac OS X),
libsbml.so (Linux), or sbmlj.dll (Windows);
both of these must be installed and shipped with applications
along with the core libSBML library file. Please refer to section
Files installed by libSBML, and their locations)
for an explanation of the name and location of the libSBML library file
under different operating systems.
A warning about Java versions: we have been unable to successfully compile the libSBML Java interface using the GNU Compiler for Java (gcj), at least in the case of gcj version 4.4.3 under Ubuntu Linux version 10.10. We do not recommend using gcj with libSBML for this reason.
On some hardware and operating system combinations, it is possible to
compile 64-bit as well as 32-bit versions of programs. Normally, the most
sensible default will be chosen by the systems' compilers automatically,
but when you download third-party software or compile your own, sometimes
it becomes necessary to select specific versions. LibSBML is no exception.
To make it easier to build libSBML explicitly in a 32-bit or 64-bit
version, configure offers the two optional arguments
--enable-m32--enable-m64
Whether you need to do this depends very much on your hardware, operating system, and the format of other libraries and programs on your system. Currently, the most common situation where this issue arises is on 64-bit systems where not all libraries (e.g., the XML parser libraries) are available in 64-bit format. Then, libSBML needs to be configured to be built as a 32-bit binary:
./configure --enable-m32
The two options --enable-m32--enable-m64configure and is discussed in
the next section.
Apple Macintosh operating systems versions 10.4–10.6 provide the
option of building binaries that can run natively on either PowerPC or x86
(Intel) architectures, as well as in either 32-bit or 64-bit versions.
Compiling a library to be a so-called universal binary containing
multiple versions of the object code requires the use of special options at
compilation time. To configure libSBML to be built as a universal binary,
specify the optional argument
--enable-universal-binaryconfigure. The following example illustrates how to do this:
./configure --enable-universal-binary
By default, on Mac OS 10.5, the libSBML option above will construct a
universal binary containing 32-bit PowerPC and 32-bit Intel x86 binaries;
on Mac OS 10.6, this becomes 32-bit PowerPC, 32-bit x86, and
64-bit x86 binaries. If you want to build universal binaries with a different
combination of CPU architectures, then you can specify it as an optional
argument to the --enable-universal-binary
./configure --enable-universal-binary="-arch i386 -arch ppc -arch x86_64 -arch ppc64"
Beware that building with this option turn on results in the creation of larger libSBML binary files, because the files contain essentially two copies of the same code (one for each architecture).
Finally, if both --enable-universal-binary--enable-m32--enable-m64--enable-universal-binary
Important: libSBML is known to work with SWIG version 2.0.0 or later; earlier versions are known not to work. You must use version 2.0.0 or later.
SWIG is the
Simplified Wrapper and Interface Generator and in libSBML it is used
to create the bindings for C#, Java, JavaScript, Python, and other
programming languages. To configure libSBML to use SWIG, use the
--with-swigconfigure. If
your copy of SWIG is installed in a location where configure
cannot find it on its own, you can specify it as an optional argument to the
--with-swig
./configure --with-swig="DIR"
LibSBML provides built-in support for reading and writing compressed
SBML files. This facility works transparently: if a given SBML filename
ends with one of the suffixes recognized for a compressed file (namely,
.gz, .zip, or .bz2), the libSBML
readSBML() method will automatically decompress the file upon
reading it and the writeSBML() method will compress the file
upon writing it. (Files whose names have no extensions are read and
written in uncompressed form.)
These features are enabled by default if the required libraries can be
found on your system. The libraries are the zlib library (for the gzip and
zip formats) and the bzip2 library (for the bzip2
format). If the libSBML configure program cannot find the libraries in the
locations where it searches by default, you can inform the configure
program where to look by adding the flag
--with-zlib=DIRlib directory where the zlib library is located, and/or the
flag --with-bzip2=DIRlib directory where the bzip2 library is located.
To selectively disable specific library checks and format support, add
the option --with-zlib=no--with-bzip2=no--enable-compression=no
./configure --enable-compression=no
LibSBML comes with extensive documentation, and the document you are
currently reading is part of it. Because the documentation is large and
regenerating it requires the use of software tools that not all users may
have, the authors of libSBML supply a separate downloadable archive
containing only the documentation. The documentation archive file has a
name of the form libsbml-VERSION-docs.zip, where
VERSION is the version of
libSBML. After you download it, you can simply unzip the file in the same
location as your libSBML source directory (or alternatively, in any other
location that suits you). We recommend downloading the ready-made
documentation archive as the easiest way to get the libSBML documentation.
The same documentation files should also be available online at http://sbml.org/Software/libSBML/, although this online copy normally corresponds to the last stable release of libSBML and may not be up-to-date with the latest development version of libSBML in the SVN repository on SourceForge.
If you would like to generate the documentation yourself, you will need the following software tools in addition to a Unix-like environment (or Cygwin under Windows):
--with-doxygenconfigure
program. Tip for Macintosh users: if you are on a Mac OS X
system and you installed the binary distribution of Doxygen from the
.dmg image provided by Doxygen's author, you will need to
point configure to the doxygen executable inside the package
for Doxygen:
./configure --with-doxygen=/Applications/Doxygen.app/Contents/Resources
--with-javaconfigure.
Once libSBML is configured as above, you can generate the documentation
files by running make docsdocs/src subdirectory and
execute
make java-manual # Note: use 'gmake java-manual' on FreeBSDto recreate just the Java documentation, or
make cpp-manual # Note: use 'gmake cpp-manual' on FreeBSDto recreate just the C++ documentation, or
make c-manual # Note: use 'gmake c-manual' on FreeBSDto recreate just the C documentation, or
make python-manual # Note: use 'gmake python-manual' on FreeBSDto recreate just the Python documentation.
libSBML provides built-in facilities for testing itself. To run the
unit tests, a second library is required, libcheck (version
0.9.2 or higher). Check is a very lightweight C unit test
framework based on the xUnit framework popularized by Kent Beck and eXtreme
Programming. Check is quite small and once installed, it consists of
only two files: libcheck.a and check.h. To
install Check, you may first want to examine whether it is easily available
via a software package manager for your system (e.g., Synaptic under
Ubuntu Linux, MacPorts or Fink under Mac OS X, etc.); if not,
you can also download Check from http://check.sf.net/.
(Note: If you are using g++ version 3.3, you will need to avoid using Check version 0.9.5, and instead use version 0.9.2. The problem is an incompatibility between Check 0.9.5 and earlier versions of g++. It appears that the compatibility problems in Check 0.9.5 disappear with versions of g++ after 3.3.)
To enable the unit testing facilities in libSBML, add the
--with-check
./configure --with-check
Following this, you must build libSBML and then you can run the tests:
make # Note: use 'gmake' on FreeBSD make check # Note: use 'gmake check' on FreeBSD
The make check step is optional and will build and run an extensive suite of unit tests to verify all facets of the library. These tests are meant primarily for developers of libSBML and running them is not required for the library to function properly. All tests should pass with no failures or errors. If for some reason this is not the case on your system, please submit a bug report using the mechanisms described in the section titled "Bug Reports, Mailing Lists, and Related Topics" elsewhere in this manual.
After the configuration step (and if you are using CMake, the generation of the makefiles), the final steps are to run the compilation process followed by a command to install libSBML on your system.
If you are using CMake, then in a terminal/shell window, first
cd into the "build" directory that you indicated to CMake in the
second line of the CMake GUI during the configuration step described in
Section 1.1, Configuring using CMake above.
For instance, if your "build" directory is simply named build and
you placed it in a subdirectory of the libSBML source directory (let
SRC stand for that directory), you would simply
do the following:
cd SRC/build
Next, execute the following command to compile libSBML:
make # Note: use 'gmake' on FreeBSD
If all went well and libSBML compiled without errors, you can use the following command to install libSBML on your computer:
sudo make install # Note: use 'sudo gmake install' on FreeBSD
Once the libSBML files are installed as described above, you may need to perform additional steps so that software can find the libSBML library files at run time. Please see the instructions in the section on making libSBML accessible to your software, provided elsewhere in this documentation.
Important: parallel GNU make builds of libSBML are not
supported at this time. Attempting to use the
-jmake will not work properly and will not complete, but will
also not produce diagnostics that indicate the cause of the failure (thus
making it difficult to understand what went wrong). Do not use the
-j
If you are using GNU make and not using CMake, in a terminal/shell
window, cd to the top level of the libSBML source directory.
In the following example, let
SRC stand for that directory:
cd SRC
Next, execute the following commands to compile libSBML:
make # Note: use 'gmake' on FreeBSD
If all went well and libSBML compiled without errors, you can use the following command to install libSBML on your computer:
sudo make install # Note: use 'sudo gmake install' on FreeBSD
Once the libSBML files are installed as described in the sections above, you may need to perform additional steps so that software can find the libSBML library files at run time. Please see the separate section on making libSBML accessible to your software provided elsewhere in this documentation.
If something went wrong during the build step and the compilation of libSBML stopped with an error, it may be useful to get more information in order to debug the process.
VERBOSE=1 in the make step:
make VERBOSE=1
--debug=bmake -d. In other words, you can use the
following command:
make --debug=b
If you need to contact the libSBML Team for help with debugging a failing
libSBML build, it will greatly help us to get a record of the debugging
output from a clean build. On Linux, Mac OS X and Cygwin, you can
use the convenient script command to record input and output in
a terminal shell, and then email us the output.
make clean # Clean everything to get a fresh build script # Start recording everything in the shell make VERBOSE=1 # Build with debugging on exit # Stop recording the script
make clean # Clean everything to get a fresh build script # Start recording everything in the shell make --debug=b # Build with debugging on exit # Stop recording the script
Don't forget to type exit!
Once you type exit, the script command will
stop and leave a file named "typescript" in the current
directory. Please include the "typescript" when contacting
the libSBML Team with questions about build failures.
Whether you use CMake or GNU make, there are some additional advanced
options that are uncommonly used, but still worth explaining. We list the
options below using their names as they appear in the CMake configuration
screen; the alternative configure approach uses slightly
different command-line flag names, but still similar to the names below.
LIBSBML_SHARED_VERSION: This flag controls whether the
version number should be written into the libSBML shared library.
LIBSBML_USE_STRICT_INCLUDES: This flag is intended for
libSBML developers; it permits faster recompilation of libSBML by reducing
the files that are #include'd in certain ways, such that
changing a single libSBML class does not cause as many dependencies to be
triggered. This option makes no difference to compilation except when you
make changes to libSBML class definitions and recompile libSBML, so there is
no advantage for regular user code to enable this option.
There are two ways to compile libSBML under Windows: using the native Windows compilation tools from Microsoft, and using the Cygwin environment. In this section, we focus on using the native Windows environment because this appears to be the more popular approach used by Windows-based users of libSBML. Cygwin users can follow essentially the same instructions as for other Unix environments given above.
To create configurations suitable for compiling libSBML using the native Windows build tools, we recommend using CMake to generate them. (If you do not already have CMake installed on your system, please begin by downloading a copy of CMake version 2.8.4 or later from cmake.org.) Once you have CMake installed, also download and unzip the libSBML source code archive from the download area on SourceForge.net and save the archive somewhere on your file system, then unpack it.
Before going further, an issue on Windows concerns the dependency libraries on which libSBML depends. CMake will try to find all the dependencies for the default options, which leads to problems if they do not exist. We recommend Windows users download the dependencies we have prepackaged at the following download location:
Download and extract this file into the same folder where you unpacked
the libSBML source distribution. CMake will look for these dependencies in
a folder called dependencies directly below the libSBML root
folder.
Once you have the libSBML sources and the dependency libraries unpacked on your system, start up the CMake graphical user interface (GUI). It will look something like the following screenshot:
Screenshot of CMake when it first starts up.
Click on the Browse Source... button and navigate to the directory
where you unpacked the libSBML source code archive on your file system.
CMake should automatically fill in the next line, Where to build the
binaries, using a subdirectory named build within the
directory where your source code is located. (If it does not, fill in the
field in the CMake interface yourself.) Then, click on the
Configure button. CMake should display a dialog similar to the
following.
Screenshot of the Configure screen under Microsoft Windows 7. Choose the settings appropriate for the build environment you are using and click the Finish button.
After you close the configuration screen, CMake will populate the options area with various options it reads from the libSBML configuration files. These new options are displayed in red, as illustrated in the following screenshot.
Screenshot of the CMake interface after the configuration step.
In this panel, you can set values for various libSBML configuration/build
options. For example, you can set the location into which the compiled
libSBML libraries will be installed by clicking on the line for
CMAKE_INSTALL_PREFIX and replacing the default value with a
value of your choosing. To find out the meaning of a particular option,
hover your mouse/pointer over the item for a few seconds until the tooltip
text appears.
Select the options with which you wish to build libSBML. All the
options for configuring libSBML, including language bindings and SBML
Level 3 packages, are listed here and may be selected/deselected as
required. For instance, to include the Java language bindings, click the
check-box for WITH_JAVA. Once you are done configuring, click
on CMake's Configure button. CMake will process the configuration,
and if it lacks any information, it will highlight the options in red. You
may need to iterate between setting options and clicking the
Configure button until there are no options left in red and the
Generate button becomes enabled.
Next, click on the Generate button. This will cause CMake to create project configuration files ("Solutions") for the compilation environment you selected in the beginning (e.g., Visual Studio 2010).
The MSVC Solution will contain a number of projects files, depending on the configuration selected. The following screenshot illustrates what you should see when you use the Solution Explorer in MSVC, and some of the most important targets that you will find there:
Screenshot of MSVC's Solution Explorer when viewing the MSVC Solution files generated using CMake.
ALL_BUILD: This target builds
all the libSBML project files; that is, all projects except the ones that
involve installation, packaging or testing.
INSTALL: This target will
install the compiled binaries to the directory specified for the
CMAKE_INSTALL_PREFIX option of the CMake configuration step.
ZERO_CHECK: This target is
merely a verification project; it is used to check whether there have been
any changes to the configuration since the last time it was run. It is
invoked automatically whenever any other target is being built.
PACKAGE: This target creates
binary installers for libSBML. If the Nullsoft scriptable installation
system, NSIS (http://nsis.sf.net) is available, an
installer is created for the current platform. Most users will not need to
use this build target/Solution.
RUN_TESTS: This target
can be used to test all the libraries built. It is only available if the
WITH_CHECK option is selected during the CMake configuration
step. (Note: the libcheck library upon which this
facility depends is incompatible with MSVC 7, so you will need to use
a newer version of MSVC if you want to try RUN_TESTS.) The
checks will fail if Windows is unable to locate the dynamic libraries, or
for each language binding if it is unable to locate both the binding
library and the libSBML native library.
Other projects generated by the libSBML CMake configuration system and listed in the MSVC Solution explorer are named to indicate the intended target. Some examples include the following:
binding_python_lib:
builds the Python language bindings _libsbml.pyd file.
binding_java_classes:
builds the Java language bindings class JAR file.
example_c_convertSBML:
builds the convertSBML example program in C.
example_java_addCVTerms: builds the addCVTerms
example program in Java.
test_sbml_math: builds
the tests in the libSBML src/math subdirectory.
A typical procedure for building libSBML using MSVC consistes of performing the following steps:
ALL_BUILD
target. After a successful build, MSVC will put the libSBML library files
and DLL into the Release subdirectory of the location
specified using CMake. This includes the language bindings, which will be
placed in a subdirectory of the Release directory. For
example, C# files will appear in Release/csharp.
INSTALL
target. This will install the compiled libSBML library and associated
files into the directory determined by the
CMAKE_INSTALL_PREFIX CMake configuration variable.
Once the libSBML files are installed as described in the sections above, you may need to perform additional steps so that software can find the libSBML library files at run time. Please see the instructions on Making libSBML accessible to your software provided on a separate page of this documentation.
If all went as it should, the libSBML object files should end up
compiled and installed on your system, in either the default location
(/usr/local/) or in the location you indicated during the
configuration step as explained above. The core libSBML library object
files will have slightly different names depending on the operating system
in use. The following table summarizes the possibilities:
| Names of core libSBML object files | |||
|---|---|---|---|
| Type of file | Linux/Unix-based OS | Mac OS X | Windows |
| Dynamically-linked | libsbml.so.5 |
libsbml.5.dylib |
libsbml.dll |
| Statically-linked | libsbml.a |
libsbml.a |
libsbml.lib |
| Libtool control file | libsbml.la |
libsbml.la |
N/A |
If you have compiled additional language extensions with libSBML, these files will be installed as well, but their names and locations depend on the particular language extension. The following two tables summarize the possibilities. The first table lists the names of the files, while the second table below lists the pathnames where those files will be installed.
| Names of language extension object files | ||||
|---|---|---|---|---|
| Language | Linux/Unix-based OS | Mac OS X | Windows | |
| C# |
|
libsbmlcs.so libsbmlcsP.dll |
libsbmlcs.so libsbmlcsP.dll |
libsbmlcs.dll libsbmlcsP.dll |
| Java |
|
libsbmlj.so libsbmlj.jar |
libsbmlj.jnilib libsbmlj.jar |
sbmlj.dll libsbmlj.jar |
| JavaScript | (Node.js module) | sbml.node |
sbml.node |
sbml.node |
| MATLAB |
|
TranslateSBML.mexglxOutputSBML.mexglx |
TranslateSBML.mexmaci
OutputSBML.mexmaci
|
TranslateSBML.mexw32OutputSBML.mexw32 |
|
|
TranslateSBML.mexa64OutputSBML.mexa64
|
TranslateSBML.mexmaci64
OutputSBML.mexmaci64
|
TranslateSBML.mexw64OutputSBML.mexw64 |
|
|
|
N/A |
TranslateSBML.mexmacOutputSBML.mexmac
|
N/A |
|
|
|
CheckAndConvert.mContents.mConvertFormulaToMathML.misSBML_Model.misoctave.m |
CheckAndConvert.mContents.mConvertFormulaToMathML.misSBML_Model.misoctave.m |
CheckAndConvert.mContents.mConvertFormulaToMathML.misSBML_Model.misoctave.m |
|
| Octave | TranslateSBML.mexOutputSBML.mexCheckAndConvert.m
Contents.mConvertFormulaToMathML.misSBML_Model.misoctave.m |
TranslateSBML.mexOutputSBML.mexCheckAndConvert.m
Contents.mConvertFormulaToMathML.misSBML_Model.misoctave.m |
TranslateSBML.mexOutputSBML.mexCheckAndConvert.m
Contents.mConvertFormulaToMathML.misSBML_Model.misoctave.m |
|
| Perl |
|
LibSBML.soLibSBML.pmLibSBML.pod.packlist |
LibSBML.bundleLibSBML.pmLibSBML.pod.packlist |
LibSBML.dllLibSBML.pmLibSBML.pod.packlist |
| Python |
|
_libsbml.solibsbml.pylibsbml.pyclibsbml.pth |
_libsbml.solibsbml.pylibsbml.pyclibsbml.pth |
_libsbml.dlllibsbml.pylibsbml.pyclibsbml.pth |
| Python |
|
_libsbml.solibsbml.pylibsbml.pyclibsbml.pth |
_libsbml.solibsbml.pylibsbml.pyclibsbml.pth |
_libsbml.pydlibsbml.pylibsbml.pyclibsbml.pth |
| R | libSBML.rdblibSBML.rdxlibSBML |
libSBML.rdblibSBML.rdxlibSBML.so |
libSBML.rdblibSBML.rdxlibSBML.dll |
|
| Ruby | libSBML.so |
libSBML.bundle |
libSBML.dll |
|
The next table gives the locations of the files listed in the table
above for Linux/Unix-based operating systems. The pathnames shown here are
relative to the prefix directory used in configuring libSBML (meaning the
value DIR given to the
--prefix=DIRconfigure program discussed above).
| Language | Directories | Notes | |
|---|---|---|---|
| C# |
(unmanaged C++ DLL) (managed C# DLL) |
/lib/mono/libsbmlcsP//lib/mono/libsbmlcsP/ |
|
| Java |
|
/lib//share/java/ |
|
| JavaScript | /lib/node/ |
||
| MATLAB | /lib/ |
||
| Octave | /lib/octave/site/oct/platform/ |
(1) | |
| Perl |
|
/lib/perl5/site_perl/perl-version/platform/auto/libSBML//lib/perl5/site_perl/perl-version/platform//lib/perl5/site_perl/perl-version/platform/ |
(2) |
| Python (Ubuntu) |
|
/lib/python-version/dist-packages/libsbml//lib/python-version/dist-packages/libsbml//lib/python-version/dist-packages/libsbml//lib/python-version/dist-packages/ |
|
| Python (Other Linux distributions) |
|
/lib/python-version/site-packages/libsbml//lib/python-version/site-packages/libsbml//lib/python-version/site-packages/libsbml//lib/python-version/site-packages/ |
(2) |
| R | /lib/R/site-library/libSBML/ |
||
| Ruby | /lib/ruby/site_ruby/ruby-version/platform/ |
||
Given the large number of variables that are involved in installing libSBML (e.g., operating systems versions, library versions, etc.), it is not impossible that issues arise when you try to get libSBML working. We offer the following tips for what to do if you encounter problems: