Tips and other help

Making libSBML compatible with different operating systems, different versions of operating systems, and different releases of programming language libraries, is a constant struggle. Here we discuss special topics that may be helpful for people facing some specific situations.

MacOSX

Configuring with libcheck on 64-bit MacOSX systems

If you attempt to configure libSBML 4.x and 5.x for some combinations of language bindings under MacOS 10.6 (aka "Snow Leopard"), it can become a real challenge to achieve binary compatibility for all libraries concerned. A case in point is attempting to build 32-bit MATLAB bindings simultaneously with the Check library (libcheck), which some MacOSX users will have installed using the MacPorts system. Unless you build libcheck as a universal binary, here's what will probably happen when you run the libSBML configure program:

1. Upon running configure with options such as --with-matlab=/Applications/MATLAB_R2010a.app --with-check=/opt/local, you will get the following error:

    libSBML needs to be built explicitly to include a 32-bit (i386) version, 
    because your copy of MATLAB is a 32-bit version.  By default, MacOS 10.6+ 
    (Snow Leopard) builds everything as 64-bit (x86_64) binaries.  Please add 
    either 
        --enable-m32 
    or 
        --enable-universal-binary="-arch i386 -arch x86_64" 
    to your configure options, re-run the configure step, and recompile.  If 
    you get a compilation error, please check whether you have a private 
    version of a dependent library (e.g., expat, libxml, or xerces) that was 
    built only as a 64-bit version, and either remove, recompile or replace it 
    it before proceeding further. 
   

2. If you then proceed to add the universal binary flag as suggested, configure will quit with a different error:

    checking for Check version >= 0.9.2... *** Could not run Check test program, trying to find out why... 
    *** The test program compiled, but did not run.  This usually 
    *** means that the run-time linker is not finding libcheck, but 
    *** could also be the result of mixing binary architectures 
    *** (e.g., trying to use a 32-bit check library while compiling 
    *** in a 64-bit environment).  At this point, it is best to 
    *** look in the file 'config.log' for clues about what happened. 
    *** 
    *** If the problem is due to the first issue, will may need 
    *** to set your LD_LIBRARY_PATH environment variable, or 
    *** edit /etc/ld.so.conf to point to the installed 
    *** location, and also run ldconfig if that is required on 
    *** your operating system.  If the problem is due to the 
    *** second (mixing architectures), you may need to obtain a 
    *** different copy of libcheck or recompile it for this 
    *** machine architecture. 
    *** 
    *** If you have an old version of Check installed, it is best 
    *** to remove it, although you may also be able to get things 
    *** to work by modifying you value of LD_LIBRARY_PATH.
   

Here's what's happening. MacOSX 10.6 builds 64-binary objects by default, and both the MATLAB R2010a installation and MacPort's libcheck are 32-bit binaries. If you enable libSBML's universal binary flag, it will fix the MATLAB compatibility issue, but at the point where libSBML attempts to test linking with libcheck, it discovers that libcheck is not available as a universal binary, and so the test fails.

The simplest solution is to use a universal (fat) binary version of libcheck. You can do this in two ways: build your own copy of the Check library from the source distribution, or reconfigure your MacPorts installation to build universal binaries and then recreate libcheck. If you choose the former option (building from the Check sources), the following configuration command for Check should work (including the backslash in the first line):

env CFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS="-arch ppc -arch i386 -arch x86_64"  \
./configure --with-pic --with-gnu-ld --disable-dependency-tracking

If, instead, you choose the latter route (changing your MacPorts configuration and reinstalling its version of libcheck), here are the steps to do that:

1. (If you have already installed MacPorts' libcheck) Uninstall libcheck using sudo port uninstall check
2. (Re)build libcheck using the command sudo port install check +universal

After doing the above, you should be able to re-run libSBML's configure with the MATLAB and libcheck flags, and it should successfully configure libSBML.

Microsoft Windows

Linux

Generic issues (not specific to a particular system)

libsbml_wrap.cpp file(s) not regenerated

Many of the language bindings in libSBML are created using SWIG, a language wrapper generator. The output of SWIG for libSBML is a file named libsbml_wrap.cpp in 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.cpp file. In both cases, all things should work fine.

If you modify the libSBML source files (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 cygwin.

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 libsbml_wrap.cpp file(s), 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.