libSBML C++ API 5.8.0
In the C-like, text-based, formula expression syntax supported by libSBML
and used in SBML Level 1, four constants are reserved words:
pi. Most of them will not easily lead to a name collision,
but unfortunately, the character sequence
pi is also
sometimes used as a species identifier by biological modelers (e.g., to use
"Pi" to represent a phosphate ion). If the string "
Pi" appears in a text string passed to a libSBML method that
interprets formulas, it will be interpreted as the mathematical constant
π (pi). For example, the expression 2 * Pi will yield
<math xmlns="http://www.w3.org/1998/Math/MathML"> <apply> <times/> <cn type="integer"> 2 </cn> <pi/> </apply> </math>
This problem exists for all four of the constants mentioned above, but is most commonly encountered in the context of "pi". Currently, the only ways to avoid this problem are either to avoid using the strings "pi" and "Pi" in this context, or to avoid using the text-string expressions altogether and instead use ASTs. All libSBML methods that accept text-string mathematical formulas have variants that accept ASTs instead.
The different parsers supported by libSBML (Xerces, Expat, libxml2) behave slightly differently when reading files, and the differences are difficult for libSBML to hide. The following are the differences of which we are currently aware:
nis a namespace prefix that is not defined, will be silently ignored. As a result, libSBML cannot catch and report this error when libSBML has been configured with this version of libxml2. We know of no workaround at this time if you are using a system with libxml2 2.6.16, except to compile your own copy of libxml2 or use another parser library. (Incredibly enough, libxml 2.6.16 built from original sources on a Mac does report the error. The only explanation is that that Apple is shipping a modified version of libxml 2.6.16 in versions of the operating system up through 10.5.8.)
xmlns=" ", with a space character). Versions of libxml prior 2.7.7 will report this as an invalid or undefined XML namespace, but in fact a namespace URI containing a single space is valid (albeit not a very useful one). This highlights another issue: different versions of the underlying XML parsers may behave differently in the face of unusual (though not necessarily illegal) inputs.
checking for Expat version >= 1.95.8... *** The Expat header file (version 2.1.0) does not match *** the Expat library found (version 2.0.1).. However if the gnumake ./configure, make & make install is used to build the Expat library the header mismatch is avoided.
string. Unfortunately, given the way that all three XML parser libraries (libxml2, Expat, and Xerces) work, it is impossible for libSBML to ever report this error directly. The kinds of SBML input that would lead to a failure of this validation rule cause the XML parsers to report overly general errors of the "XML content not well formed" variety, and libSBML cannot determine the true root cause. As a result, libSBML cannot detect when rule #10312 is breached.
libsbml.dll, depending on your operating system). If a user's environment includes an old version of this library file, and it is picked up at run-time instead of the correct library version, linking may fail with mysterious errors about undefined symbols. Users and developers are cautioned to make sure that their installations have matched versions of libSBML components and are free of older versions that may be picked up inadvertently.
make uninstall command on Linux, Mac OS, Cygwin,
and Solaris only knows about the features most recently configured
into libSBML. If you run
install, then run
configure again with different
options, and finally try
make uninstall, the result will be to
attempt removing the files implied by the most recent run of
configure, not the files installed by the
free()function call to free memory allocated and returned by libSBML. Without the ability to use
free()to free the string returned by libSBML, the calling application will leak memory. An example of typical code where one would want to free the returned by libSBML is the following:
char * formula = SBML_formulaToString(astNode); /* ... do some work with formula here ... */ free(formula);
To cope with this issue, beginning with version 4.2, libSBML provides a
special function for this situation:
setLevelAndVersion()on the class
SBMLDocumentperforms conversion between versions and levels of SBML (to the extent possible within technical and practical limits). However, conversion to/from SBML Level 1 Version 1 is not supported.
XMLErrorwill be set to either
0or the value of the maximum unsigned long integer representable on the platform where libSBML is running. The probability that a true line or column number in a real-life SBML model would equal this value is vanishingly small; thus, if an application encounters these values in an XMLError object, it can assume no valid line/column number could be provided by libSBML in that situation. SWIG, a language wrapper generator. The output of SWIG for libSBML is a file named
libsbml_wrap.cppin the respective language binding's subdirectory (e.g.,
src/bindings/java), sometimes in combination with other files, depending on the language in question. If you obtained your copy of libSBML as a distribution archive (e.g., from SourceForge), this file will already be present in the distribution. If, instead, you obtained your copy of libSBML from the SVN source tree, you will need to have SWIG available on your system in order to regenerate the
libsbml_wrap.cppfile. In both cases, all things should work fine.
If you modify the libSBML source files yourself (and in
particular, files upon which the SWIG binding code depends), the makefile
rules should always automatically cause the appropriate
libsbml_wrap.cpp files to be recreated. However,
sometimes the makefile rules do not regenerate the wrapper files
when they should. This happens very rarely, and under conditions that the
libSBML developers have had a very hard time reproducing consistently. In
some versions of libSBML, it seemed to happen slightly more often under
When a version skew occurs with the language binding wrapper files, either the compilation phase or the link phase will fail, often with cryptic and mysterious errors about missing methods. Often it is possible to guess that the language bindings are the problem from the error messages.
The solution is to delete the
and when the Java interface is involved, also delete the
src/bindings/java/java-files subdirectory. Re-running make
will regenerate the files and (if the problem was indeed due to the SWIG
binding files being out of date) compilation/linking will work.
We emphasize that this problem should not affect normal users of libSBML, only the libSBML developers and those are are venturing into developing new features in libSBML.
The solution is to preload the system stdc++ library before invoking
MATLAB. You can accomplish this by setting the Linux environment variable
LD_PRELOAD to the path of the system's
library file. This will take the form of the following:
export LD_PRELOAD=/path/to/system/libstdc++for sh-based shells such as Bash, or
setenv LD_PRELOAD /path/to/system/libstdc++for csh-based shells.